Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Zong Li <zong.li@sifive.com>
Cc: Ron Economos <re@w6rz.net>,
	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 v5] riscv: cif: reduce shadow stack size limit from 4GB to 512MB
Date: Wed, 20 May 2026 09:51:07 +0100	[thread overview]
Message-ID: <20260520095107.1bf48926@pumpkin> (raw)
In-Reply-To: <CANXhq0r2ieA-53d=GTvLU4o2qzVTPc7pcxC_Y_pX=a=CiAB=wA@mail.gmail.com>

On Wed, 20 May 2026 13:59:44 +0800
Zong Li <zong.li@sifive.com> wrote:

> On Tue, May 19, 2026 at 5:20 PM Zong Li <zong.li@sifive.com> wrote:
> >
> > On Tue, May 19, 2026 at 4:28 PM Ron Economos <re@w6rz.net> wrote:  
> > >
> > > On 5/19/26 00:18, Zong Li wrote:  
> > > > Rationale:
> > > >
> > > > 1. Shadow stacks only store return addresses (8 bytes per entry), not
> > > >     local variables, function parameters, or saved registers. A 512MB
> > > >     shadow stack is far more than sufficient for any practical
> > > >     application, even with extremely deep recursion. This size
> > > >     maintains adequate while being more resource-efficient margin
> > > >
> > > > 2. On memory-constrained systems (e.g., platforms with only 4GB of
> > > >     physical memory, which is a common configuration), allocating 4GB
> > > >     of virtual address space for shadow stack per process/thread can
> > > >     lead to virtual memory allocation failures when the overcommit mode
> > > >     is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER:
> > > >     Error: "__vm_enough_memory: not enough memory for the allocation"
> > > >
> > > > Suggested-by: David Laight <david.laight.linux@gmail.com>
> > > > Signed-off-by: Zong Li <zong.li@sifive.com>
> > > > ---
> > > >
> > > > Changed in v4:
> > > > - Fix wrong subject. It is 512MB instead of 2GB
> > > >
> > > > Changed in v3:
> > > > - Remove max(). PAGE_ALIGN() already rounds up
> > > > - Change stack size to RLIMIT_STACK/8 with SZ_512M cap. Suggested by David Laight
> > > >
> > > > Changed in v2:
> > > > - Add max() in case RLIMIT_STACK is smaller than PAGE_SIZE. Suggested by
> > > >    Paul Walmsley and Sashiko
> > > >
> > > > Changed in v1:
> > > > - Use min() instead of min_t(). Suggested by David Laight
> > > >
> > > >   arch/riscv/kernel/usercfi.c | 6 +++---
> > > >   1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c
> > > > index 6eaa0d94fdfe..2036918a77db 100644
> > > > --- a/arch/riscv/kernel/usercfi.c
> > > > +++ b/arch/riscv/kernel/usercfi.c
> > > > @@ -109,15 +109,15 @@ void set_indir_lp_lock(struct task_struct *task, bool lock)
> > > >       task->thread_info.user_cfi_state.ufcfi_locked = lock;
> > > >   }
> > > >   /*
> > > > - * If size is 0, then to be compatible with regular stack we want it to be as big as
> > > > - * regular stack. Else PAGE_ALIGN it and return back
> > > > + * The shadow stack only stores the return address and not any variables
> > > > + * 512M should be more than sufficient for most applications.
> > > >    */
> > > >   static unsigned long calc_shstk_size(unsigned long size)
> > > >   {
> > > >       if (size)
> > > >               return PAGE_ALIGN(size);
> > > >
> > > > -     return PAGE_ALIGN(min_t(unsigned long long, rlimit(RLIMIT_STACK), SZ_4G));
> > > > +     return PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 8, SZ_512M));
> > > >   }
> > > >
> > > >   /*  
> > >
> > > Just FYI, your V2 version of this patch was merged in Linux 7.1-rc4 (commit 6c7674b5b7ae513cecae22aa9dcdcf533862cf5c). You need to
> > > rebase, otherwise this patch won't apply.  
> >  
> 
> Hi David,
> Since the original patch has been merged, would you like to send a new
> patch from your side to adjust the size? Or do you prefer that I do
> that for you? Please let me know your thoughts. Thanks

It's is probably easier for you to do it.
I'd need to find a clean enough source tree.
(I've got a part-committed set of changes to remove strcpy() from
150 files 'in progress'.)

-- David


> 
> > Thank you for pointing this out. Perhaps let's drop this series and
> > send a new one to explain why we want to reduce the size to 512MB
> >  
> > >  


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

      reply	other threads:[~2026-05-20  8:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19  7:18 [PATCH v5] riscv: cif: reduce shadow stack size limit from 4GB to 512MB Zong Li
2026-05-19  8:28 ` Ron Economos
2026-05-19  9:20   ` Zong Li
2026-05-20  5:59     ` Zong Li
2026-05-20  8:51       ` David Laight [this message]

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=20260520095107.1bf48926@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=re@w6rz.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox