[PATCH v3] riscv: cif: reduce shadow stack size limit from 4GB to 2GB

[David Laight]

On Fri, 15 May 2026 22:29:05 +0800
Zong Li <zong.li at sifive.com> wrote:

> On Fri, May 15, 2026 at 5:24 PM David Laight
> <david.laight.linux at gmail.com> wrote:
> >
> > On Fri, 15 May 2026 11:42:45 +0800
> > Zong Li <zong.li at 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).
> >  
> 
> You raise a valid point that shadow stacks are primarily a VA
> allocation. However, in Linux, the memory overcommit mechanism creates
> a practical link between VA allocation and physical memory capacity.
> As I mentioned in the commit message, memory allocation will fail when
> the overcommit mode is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER.
> 
> In __vm_enough_memory:
>         if (pages > totalram_pages() + total_swap_pages)
>                 goto error;
> 
> Many page requests for VA will fail if the requested size exceeds the
> system's total RAM plus Swap. On memory-constrained systems,
> allocating a massive 4GB shadow stack per thread would immediately
> trigger this error.

But reducing the size by half makes little difference.
You'd need a much bigger reduction to make any real difference.

-- David

> 
> > 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  
>