All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Deepak Gupta <debug@rivosinc.com>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Will Deacon <will@kernel.org>, Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 5/5] mm: Do not map the shadow stack as THP
Date: Wed, 25 Feb 2026 15:51:20 +0000	[thread overview]
Message-ID: <aZ8aeHpn_KElP2jm@arm.com> (raw)
In-Reply-To: <5570c06d-fbc1-42c9-9b27-26211e8b033c@sirena.org.uk>

On Wed, Feb 25, 2026 at 01:02:36PM +0000, Mark Brown wrote:
> On Tue, Feb 24, 2026 at 05:57:57PM +0000, Catalin Marinas wrote:
> > The default shadow stack size allocated on first prctl() for the main
> > thread or subsequently on clone() is either half of RLIMIT_STACK or half
> > of a thread's stack size (for arm64). Both of these are likely to be
> > suitable for a THP allocation and the kernel is more aggressive in
> > creating such mappings. However, it does not make much sense to use a
> > huge page. It didn't make sense for the normal stacks either, see commit
> > c4608d1bf7c6 ("mm: mmap: map MAP_STACK to VM_NOHUGEPAGE").
> 
> Reviewed-by: Mark Brown <broonie@kernel.org>

Thanks.

> The create THP and immediately splitting it pattern is very clear when
> checking the mm behaviour on new GCSs, this should help performance.

If the first access is a write, the kernel allocates a THP from the
start without subsequent splitting. Also since 6.13 (commit 1ced09e0331f
"mm: allocate THP on hugezeropage wp-fault"), we go for another THP on
write. It's still wasting memory and time to zero the full 2MB when
it's highly unlikely we'd ever use that much for a shadow stack.

-- 
Catalin


WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Deepak Gupta <debug@rivosinc.com>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Will Deacon <will@kernel.org>, Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 5/5] mm: Do not map the shadow stack as THP
Date: Wed, 25 Feb 2026 15:51:20 +0000	[thread overview]
Message-ID: <aZ8aeHpn_KElP2jm@arm.com> (raw)
In-Reply-To: <5570c06d-fbc1-42c9-9b27-26211e8b033c@sirena.org.uk>

On Wed, Feb 25, 2026 at 01:02:36PM +0000, Mark Brown wrote:
> On Tue, Feb 24, 2026 at 05:57:57PM +0000, Catalin Marinas wrote:
> > The default shadow stack size allocated on first prctl() for the main
> > thread or subsequently on clone() is either half of RLIMIT_STACK or half
> > of a thread's stack size (for arm64). Both of these are likely to be
> > suitable for a THP allocation and the kernel is more aggressive in
> > creating such mappings. However, it does not make much sense to use a
> > huge page. It didn't make sense for the normal stacks either, see commit
> > c4608d1bf7c6 ("mm: mmap: map MAP_STACK to VM_NOHUGEPAGE").
> 
> Reviewed-by: Mark Brown <broonie@kernel.org>

Thanks.

> The create THP and immediately splitting it pattern is very clear when
> checking the mm behaviour on new GCSs, this should help performance.

If the first access is a write, the kernel allocates a THP from the
start without subsequent splitting. Also since 6.13 (commit 1ced09e0331f
"mm: allocate THP on hugezeropage wp-fault"), we go for another THP on
write. It's still wasting memory and time to zero the full 2MB when
it's highly unlikely we'd ever use that much for a shadow stack.

-- 
Catalin

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-02-25 15:51 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24 17:57 [PATCH 0/5] mm: arch/shstk: Common shadow stack mapping helper and VM_NOHUGEPAGE Catalin Marinas
2026-02-24 17:57 ` Catalin Marinas
2026-02-24 17:57 ` [PATCH 1/5] mm: Introduce vm_mmap_shadow_stack() as a helper for VM_SHADOW_STACK mappings Catalin Marinas
2026-02-24 17:57   ` Catalin Marinas
2026-02-24 19:47   ` Edgecombe, Rick P
2026-02-24 19:47     ` Edgecombe, Rick P
2026-02-25 12:25   ` Mark Brown
2026-02-25 12:25     ` Mark Brown
2026-02-25 13:32   ` David Hildenbrand (Arm)
2026-02-25 13:32     ` David Hildenbrand (Arm)
2026-02-24 17:57 ` [PATCH 2/5] arm64: gcs: Use the new common vm_mmap_shadow_stack() helper Catalin Marinas
2026-02-24 17:57   ` Catalin Marinas
2026-02-25 13:32   ` David Hildenbrand (Arm)
2026-02-25 13:32     ` David Hildenbrand (Arm)
2026-02-25 13:41   ` Mark Brown
2026-02-25 13:41     ` Mark Brown
2026-02-24 17:57 ` [PATCH 3/5] riscv: shstk: " Catalin Marinas
2026-02-24 17:57   ` Catalin Marinas
2026-02-25 13:33   ` David Hildenbrand (Arm)
2026-02-25 13:33     ` David Hildenbrand (Arm)
2026-02-24 17:57 ` [PATCH 4/5] x86: " Catalin Marinas
2026-02-24 17:57   ` Catalin Marinas
2026-02-24 19:47   ` Edgecombe, Rick P
2026-02-24 19:47     ` Edgecombe, Rick P
2026-02-25  8:12     ` Catalin Marinas
2026-02-25  8:12       ` Catalin Marinas
2026-02-25 13:33   ` David Hildenbrand (Arm)
2026-02-25 13:33     ` David Hildenbrand (Arm)
2026-02-24 17:57 ` [PATCH 5/5] mm: Do not map the shadow stack as THP Catalin Marinas
2026-02-24 17:57   ` Catalin Marinas
2026-02-25 13:02   ` Mark Brown
2026-02-25 13:02     ` Mark Brown
2026-02-25 15:51     ` Catalin Marinas [this message]
2026-02-25 15:51       ` Catalin Marinas
2026-02-25 16:10       ` Mark Brown
2026-02-25 16:10         ` Mark Brown
2026-02-25 13:34   ` David Hildenbrand (Arm)
2026-02-25 13:34     ` David Hildenbrand (Arm)
2026-02-25  0:06 ` [PATCH 0/5] mm: arch/shstk: Common shadow stack mapping helper and VM_NOHUGEPAGE Deepak Gupta
2026-02-25  0:06   ` Deepak Gupta
2026-02-25  8:08   ` Catalin Marinas
2026-02-25  8:08     ` Catalin Marinas

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=aZ8aeHpn_KElP2jm@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=bp@alien8.de \
    --cc=broonie@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=debug@rivosinc.com \
    --cc=hpa@zytor.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mingo@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@kernel.org \
    --cc=will@kernel.org \
    /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.