public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>,
	GNU C Library <libc-alpha@sourceware.org>
Cc: nd@arm.com
Subject: Re: [PATCH][BZ #11787] Fix stack guard size accounting
Date: Mon, 08 Jan 2018 15:20:00 -0000	[thread overview]
Message-ID: <eef573ca-9685-7c45-5ed9-f2c5aeaa62ea@redhat.com> (raw)
In-Reply-To: <5A2FE5ED.1080300@arm.com>

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  <szabolcs.nagy@arm.com>
> 
> 	[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)
* Second patch removed the unused pthread_attr_r and renames __pthread_get_minstack
  to avoid usage by other programs.

-- 
Cheers,
Carlos.

  parent reply	other threads:[~2018-01-08 15:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-12 14:21 Szabolcs Nagy
2017-12-18 10:28 ` Szabolcs Nagy
2017-12-20 13:09 ` Florian Weimer
2017-12-20 14:55   ` Szabolcs Nagy
2017-12-20 17:46 ` Carlos O'Donell
2017-12-20 21:24   ` Florian Weimer
2018-01-08 15:20 ` Carlos O'Donell [this message]
2018-01-08 15:22   ` Florian Weimer
2018-01-08 15:37     ` Carlos O'Donell
2018-01-08 15:41     ` Szabolcs Nagy
2018-01-08 15:43       ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eef573ca-9685-7c45-5ed9-f2c5aeaa62ea@redhat.com \
    --to=carlos@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=nd@arm.com \
    --cc=szabolcs.nagy@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).