All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Gabriel Paubert <paubert@iram.es>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org, dja@axtens.net
Subject: Re: [PATCH v2 2/5] powerpc: Allow 4224 bytes of stack expansion for the signal frame
Date: Mon, 27 Jul 2020 22:28:09 +1000	[thread overview]
Message-ID: <87mu3l6t2e.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20200727082331.GA2110@lt-gp.iram.es>

Gabriel Paubert <paubert@iram.es> writes:
> On Fri, Jul 24, 2020 at 07:25:25PM +1000, Michael Ellerman wrote:
>> We have powerpc specific logic in our page fault handling to decide if
>> an access to an unmapped address below the stack pointer should expand
>> the stack VMA.
>> 
>> The code was originally added in 2004 "ported from 2.4". The rough
>> logic is that the stack is allowed to grow to 1MB with no extra
>> checking. Over 1MB the access must be within 2048 bytes of the stack
>> pointer, or be from a user instruction that updates the stack pointer.
>> 
>> The 2048 byte allowance below the stack pointer is there to cover the
>> 288 byte "red zone" as well as the "about 1.5kB" needed by the signal
>> delivery code.
>> 
>> Unfortunately since then the signal frame has expanded, and is now
>> 4224 bytes on 64-bit kernels with transactional memory enabled.
>
> Are there really users of transactional memory in the wild? 

Not many that I've heard of, but some.

Though anything that does use it needs to be written to fallback to
regular locking if TM is not available anyway.

> Just asking because Power10 removes TM, and Power9 has had some issues
> with it AFAICT.

It varies on different Power9 chip levels. For guests it should work.

> Getting rid of it (if possible) would result in smaller signal frames,
> with simpler signal delivery code (probably slightly faster also).

All the kernel code should be behind CONFIG_PPC_TRANSACTIONAL_MEM.

Deciding to disable that is really a distro decision.

In upstream we tend not to drop support for existing hardware while
people are still using it. But we could make a special case for TM,
because it's quite intrusive. I think we'd wait for a major distro to
ship without TM enabled before we did that though.

cheers

  reply	other threads:[~2020-07-27 12:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24  9:25 [PATCH v2 1/5] selftests/powerpc: Add test of stack expansion logic Michael Ellerman
2020-07-24  9:25 ` Michael Ellerman
2020-07-24  9:25 ` [PATCH v2 2/5] powerpc: Allow 4224 bytes of stack expansion for the signal frame Michael Ellerman
2020-07-24  9:25   ` Michael Ellerman
2020-07-27  8:23   ` Gabriel Paubert
2020-07-27 12:28     ` Michael Ellerman [this message]
2020-07-27 10:50   ` Daniel Axtens
2020-07-24  9:25 ` [PATCH v2 3/5] selftests/powerpc: Update the stack expansion test Michael Ellerman
2020-07-24  9:25   ` Michael Ellerman
2020-07-24  9:25 ` [PATCH v2 4/5] powerpc/mm: Remove custom stack expansion checking Michael Ellerman
2020-07-24  9:25   ` Michael Ellerman
2020-07-27 13:48   ` Daniel Axtens
2020-07-28  2:32     ` Michael Ellerman
2020-07-24  9:25 ` [PATCH v2 5/5] selftests/powerpc: Remove powerpc special cases from stack expansion test Michael Ellerman
2020-07-24  9:25   ` Michael Ellerman
2020-07-30 12:50 ` [PATCH v2 1/5] selftests/powerpc: Add test of stack expansion logic Michael Ellerman
2020-07-30 12:50   ` Michael Ellerman

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=87mu3l6t2e.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=dja@axtens.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paubert@iram.es \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.