All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Zong Li <zong.li@sifive.com>
Cc: pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
	alex@ghiti.fr, debug@rivosinc.com,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] riscv: cif: reduce shadow stack size limit from 4GB to 2GB
Date: Fri, 15 May 2026 10:24:11 +0100	[thread overview]
Message-ID: <20260515102411.4d3e868a@pumpkin> (raw)
In-Reply-To: <CANXhq0rY8wb-0x2whLGMSuWLujtZwrEsmpWh_PUhxoZ0gpA96w@mail.gmail.com>

On Fri, 15 May 2026 11:42:45 +0800
Zong Li <zong.li@sifive.com> wrote:

> On Thu, May 14, 2026 at 4:56 PM David Laight
..
> > I also don't understand the rational for just /2 and the 2G upper limit.
> > You need 512 nested function calls to even use 4k.
> > That would have to be quite deep recursion.  
> 
> During the discussions about the ARM GCS v3 series, community pointed
> out that a 4G shadow stack might be too large. This size is hard to
> support in memory-constrained environments like Android. However, the
> size cannot be too small either, or we might face stack overflow
> issues. At that time, a perfect size was not decided.

It is only VA not real memory so shouldn't make much difference to memory
use (except for nommu where the actual memory has to be allocated).

But 32bit programs with lots of threads can run out of VA.
Increasing the stack VA size by 50% might even give problems for 64bit
programs - if they are already reducing the thread stack size avoid
running out of VA.

I've not checked, but pthread_attr_setstacksize() sets a limit for the
thread stack size (which would otherwise default so rlimit(STACK)).
I don't believe it should update the rlimit value itself.
In which case you are using the wrong size.

But for a thread with a very reduced stack (say 128k) you probably only
need 1 page of shadow stack, any more could easily lead to running out
of VA.

-- David

WARNING: multiple messages have this Message-ID (diff)
From: David Laight <david.laight.linux@gmail.com>
To: Zong Li <zong.li@sifive.com>
Cc: pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
	alex@ghiti.fr, debug@rivosinc.com,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] riscv: cif: reduce shadow stack size limit from 4GB to 2GB
Date: Fri, 15 May 2026 10:24:11 +0100	[thread overview]
Message-ID: <20260515102411.4d3e868a@pumpkin> (raw)
In-Reply-To: <CANXhq0rY8wb-0x2whLGMSuWLujtZwrEsmpWh_PUhxoZ0gpA96w@mail.gmail.com>

On Fri, 15 May 2026 11:42:45 +0800
Zong Li <zong.li@sifive.com> wrote:

> On Thu, May 14, 2026 at 4:56 PM David Laight
..
> > I also don't understand the rational for just /2 and the 2G upper limit.
> > You need 512 nested function calls to even use 4k.
> > That would have to be quite deep recursion.  
> 
> During the discussions about the ARM GCS v3 series, community pointed
> out that a 4G shadow stack might be too large. This size is hard to
> support in memory-constrained environments like Android. However, the
> size cannot be too small either, or we might face stack overflow
> issues. At that time, a perfect size was not decided.

It is only VA not real memory so shouldn't make much difference to memory
use (except for nommu where the actual memory has to be allocated).

But 32bit programs with lots of threads can run out of VA.
Increasing the stack VA size by 50% might even give problems for 64bit
programs - if they are already reducing the thread stack size avoid
running out of VA.

I've not checked, but pthread_attr_setstacksize() sets a limit for the
thread stack size (which would otherwise default so rlimit(STACK)).
I don't believe it should update the rlimit value itself.
In which case you are using the wrong size.

But for a thread with a very reduced stack (say 128k) you probably only
need 1 page of shadow stack, any more could easily lead to running out
of VA.

-- David

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

  reply	other threads:[~2026-05-15  9:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14  7:50 [PATCH v3] riscv: cif: reduce shadow stack size limit from 4GB to 2GB Zong Li
2026-05-14  7:50 ` Zong Li
2026-05-14  8:56 ` David Laight
2026-05-14  8:56   ` David Laight
2026-05-15  3:42   ` Zong Li
2026-05-15  3:42     ` Zong Li
2026-05-15  9:24     ` David Laight [this message]
2026-05-15  9:24       ` David Laight
2026-05-15 14:29       ` Zong Li
2026-05-15 14:29         ` Zong Li
2026-05-15 19:16         ` David Laight
2026-05-15 19:16           ` David Laight

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=20260515102411.4d3e868a@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=debug@rivosinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=zong.li@sifive.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 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.