From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) by sourceware.org (Postfix) with ESMTPS id 494793857C43 for ; Mon, 1 Nov 2021 17:17:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 494793857C43 X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5AA9F6E0C27; Mon, 1 Nov 2021 17:17:46 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7C5FC6E0C6B; Mon, 1 Nov 2021 17:17:43 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.105.57.75 (trex/6.4.3); Mon, 01 Nov 2021 17:17:46 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Dime-Callous: 6116e3896eeb9884_1635787065680_3270129429 X-MC-Loop-Signature: 1635787065680:4285715398 X-MC-Ingress-Time: 1635787065680 Received: from [192.168.1.174] (unknown [1.186.121.164]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4HjfqT1112z1qS; Mon, 1 Nov 2021 10:17:40 -0700 (PDT) Message-ID: <65280714-a0f4-a649-204d-bf12d0972bb9@sourceware.org> Date: Mon, 1 Nov 2021 22:47:34 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Subject: Re: sbrk() failure while processing tunables Content-Language: en-US To: Adhemerval Zanella , Libc-alpha , Carlos O'Donell , DJ Delorie References: From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3488.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, RCVD_IN_SBL, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 17:17:51 -0000 On 11/1/21 22:24, Adhemerval Zanella wrote: > And the issue seems that tunables_strdup() does calls srbk() to allocate the new > string. On a059f9505bbef1 we changed to return a _dl_fatal_printf since BZ#25035 > states that in practice no setting a tunable should not prevent the process > start. > > I commented it with Carlos on the weekly call and he brought that he has discussed > it internally. My question is there something preventing us to provide a mmap() > allocator similar to the one used by rtld_malloc to used along with tunables? > > I think using an explicit allocator disjointed from rtld_malloc (since it might > free blocks either in default or error path) should provide a more robust tunables > experience. Straight up mmap should be fine I think. AFAICT, we should have to allocate exactly once, to copy the tunable string. Thanks, Siddhesh