From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76307 invoked by alias); 11 Dec 2019 22:01:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 76162 invoked by uid 89); 11 Dec 2019 22:00:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-17.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,UNSUBSCRIBE_BODY autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576101656; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to; bh=TFrI3V6T7lOAem+INMF0OD499IXd3Q4v2n0h6aq6LAo=; b=Nrqir7qNxPgRwFkVNhGhKSmy2WuOujeNJ+Khm42kSgwzWKW3So9yKB5RlvO/FNDB/xOczN EL0VKM1xLuAfxDMV8qSxeLPq8NHXonECIUsYJo7xUZpeK0qqHysv8EBxsCb6N1Zlv5mNvV 4CCYd/DIkyjoipgvZDoRexFN3f6LuOE= From: DJ Delorie To: Siddhesh Poyarekar Cc: codonell@redhat.com, libc-alpha@sourceware.org Subject: Re: RFC: tunables failure indications... In-Reply-To: (message from Siddhesh Poyarekar on Tue, 10 Dec 2019 22:05:31 +0530) Date: Wed, 11 Dec 2019 22:01:00 -0000 Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-12/txt/msg00396.txt.bz2 Siddhesh Poyarekar writes: >> No, in the case DJ and I were looking at this was a static vs. ASLR vs. >> kernel VMA layout issue where we still have kernel issues on less >> maintstream architectures. We still need to fail safe in those cases >> and I think we should just shut the process down with appropriate error >> messages. > > OK, I was just wondering if this was a kernel bug. Either ways, > shutting down with an error sounds good, preferably in the ld.so way > (i.e. write to stderr and _exit()) rather than a forced segfault. How about this? diff --git a/elf/dl-tunables.c b/elf/dl-tunables.c index e625ac1a7d..b55d677aee 100644 --- a/elf/dl-tunables.c +++ b/elf/dl-tunables.c @@ -45,12 +45,15 @@ tunables_strdup (const char *in) while (in[i++] !=3D '\0'); char *out =3D __sbrk (i); =20 - /* FIXME: In reality if the allocation fails, __sbrk will crash attempti= ng to - set the thread-local errno since the TCB has not yet been set up. Th= is - needs to be fixed with an __sbrk implementation that does not set - errno. */ + /* For most of the tunables code, we ignore user errors. However, + this is a system error - and running out of memory at program + startup should be reported, so we do. */ if (out =3D=3D (void *)-1) - return NULL; + { +#define SBRKMSG "sbrk() failure while processing tunables" + write (2, SBRKMSG, sizeof(SBRKMSG) - 1); + _exit (1); + } =20 i--; =20