From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89197 invoked by alias); 8 Jan 2018 15:22:47 -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 89187 invoked by uid 89); 8 Jan 2018 15:22:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com Subject: Re: [PATCH][BZ #11787] Fix stack guard size accounting To: Carlos O'Donell , Szabolcs Nagy , GNU C Library Cc: nd@arm.com References: <5A2FE5ED.1080300@arm.com> From: Florian Weimer Message-ID: <7a6cf3bb-3b98-e66f-0d8d-a3a9c73a528d@redhat.com> Date: Mon, 08 Jan 2018 15:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-01/txt/msg00239.txt.bz2 On 01/08/2018 04:20 PM, Carlos O'Donell wrote: > On 12/12/2017 06:21 AM, Szabolcs Nagy wrote: >> Previously if user requested S stack and G guard when creating a >> thread, the total mapping was S and the actual available stack was >> S - G - static_tls, which is not what the user requested. >> >> This patch fixes the guard size accounting by pretending the user >> requested S + G stack. This way all later logic works out except >> when reporting the user requested stack size (pthread_getattr_np) >> or when computing the minimal stack size (__pthread_get_minstack). >> >> Normally this will increase thread stack allocations by one page. >> TLS accounting is not affected, that will require a separate fix. >> >> 2017-12-12 Szabolcs Nagy >> >> [BZ #11787] >> * nptl/allocatestack.c (allocate_stack): Add guardsize to stacksize. >> * nptl/nptl-init.c (__pthread_get_minstack): Remove guardsize from >> stacksize. >> * nptl/pthread_getattr_np.c (pthread_getattr_np): Likewise. >> > > Any status on this? > > I would like to get this in as soon as possible because the current > Intel fxsave/xsave/xsavec consume more stack than before, and we have > had at least one report of an application failing because of the additional > stack usage (breaks ntpd helper threads running with PTHREAD_STACK_MIN, see > the other discussion about what good is PTHREADS_STACK_MIN). > > It looks like a next step would be: > > * Split into two patches. > * First patch is as you intended (and can be checked in right away) Agreed. > * Second patch removed the unused pthread_attr_r and renames __pthread_get_minstack > to avoid usage by other programs. The proposed second patch *still* breaks Rust programs with large static TLS data because it will switch to PTHREAD_STACK_MIN. We should do this only after __pthread_get_minstack turns constant (that is, returns PTHREAD_STACK_MIN). Thanks, Florian