From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CECF93AA187 for ; Wed, 20 May 2026 08:51:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779267073; cv=none; b=o3ivOZq+IdUZVfbcujgi+giMYPti47kVzcFdGhmNcd/KQm7ZxUgiJ+pRUhGD+1IgJiMV7I+hLciNoN3ELZVXEq6Ne0MgRyLRGuNua9vKtjN9NeaN4GEujJr5iPp6ligs7r3nMUFTDAx11ALLgqZgwjP40mCORjJxL64ngWygJys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779267073; c=relaxed/simple; bh=gHPi+vl/Jve5zrdsD8LoFc5pSvuVEj9qfFyqGBv+bz8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FmirJnvO/6VEjbt5UAIrFkQojlhdRYdN4sHeYSo3+AFcBQ3NgeLW1wfmHU5GtgHXl38HrWnmlFuRcvJmF7wAqEgOxIKsQgba8tLEdHy2QzGD/fC5UxkiuzFytol7SW+e2cA8KWK7qa8G8tpVkBNe1pv4K2uMrPkFD6oNf7DFEFs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=g9p/N66h; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="g9p/N66h" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-488ad135063so36607315e9.0 for ; Wed, 20 May 2026 01:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779267070; x=1779871870; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=KbvXViJel1Le/J9X4fXxBeJeobwg96GmEPUlEiUp2HM=; b=g9p/N66h6s7wGU/xe4s+3i/N96PJiXQbcIG9RIlIXgo13x76cxXHs3vYD9xc9rlEmr Z1dKClXSg0q/OXywk8KGK8p73GC8NjKLYS2ee1fkpwmwTFKu9pZDT7eBgVNqBlnWRuOU Sd/bdOP2eF65XifwuSkKcyMFY8QwLMp+BJ/Qlgj2gaXpkhdLOwI6r855TBXu3WOx79En DhFGTzMAogg5YlG1LrsPjFPGRZBL8lK7M5tBWs3aHft0imLn77gFGz2LUyEiGoT5/a8o WG1Id0pk0ZfFF7D/sJ5pJA5sIfzUL2PEuypbJuYPbTFxm3DiZhgUyDKEK25j2iUf+1x+ 33Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779267070; x=1779871870; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=KbvXViJel1Le/J9X4fXxBeJeobwg96GmEPUlEiUp2HM=; b=j8ZEMVb2NpWH7+TpVq3E2EhjinRD0dQ7gCdsbA0v3XgMMagGWKTgKbf2cKvWlQJjeI VWdIwOqvk2qRKY5bZp3pAArxyC3dg9jWuJUB/demZA3oTJRlXCHen1bvHouwVl1JJnk7 W0Hf/MnVxmj4dmu6iY2oQ1M+ssRZmktKrmLy43igueU5p11zk6d8Bhhiv3KEq3x3VNFQ 3a429AUEr0cuTV2GWT7cdrL5vV5WBhciG0uUvkSkah+tAi3vrqarMLtrhUiW24E9xGIc Lvsqgq11zuI5VfGH1DYFBNGX/tK7C452ujv+Q9OFT3Hp5xcFhqLW7Sj11WFuB//Q0iRQ HRnw== X-Forwarded-Encrypted: i=1; AFNElJ8p3aLOq3bvUKtQmNcXWhAyUHjWIuLE8xNSkRBGMS8/HMlMzyQKcElB350B4NpfiHJ6ImUbwUbp/ty2qNA=@vger.kernel.org X-Gm-Message-State: AOJu0YwG46JdF6A1YDoZAMG7bS1ckt2vREZXTDqJnNFM6xCEWMH10T+z 0v0Z7SbxNl/deRdHGH+D2qZQJXAzn5KfMDdSa8FBdiBZK6sT46mVaCx2 X-Gm-Gg: Acq92OF/qYH7zHQHYVTx1vMEMNlH+L6Yfc+SM9JweX2aGLcJ8QRWxHE62DIrzVENZUf gHuahp+/3JUfEGmuOGq8N/LK4DgBexMpI120RhmVvyjchUIt15QL64djbg2vVRiIcgQZbl36g9G K0iDPT9bV7fsfLAUNFoqzs+VHBLKW9uLxs8n/lloYO8q54TndfhD1ptLpZ3tdjcHanaXApoDarv ASYeNMcUIWblSX05Zf48g59YxQhr1/1TEnzmbCoFOb8cy1zMGnzBadbuQ86pKIXrKHol2MRSKZN MAFmuSbhAMa9aB74w7heP4EfhtT2kKbyu+4bhteGhUXYaPcoiTMr8RrO6qEAvJDugQY0cpkDmt3 X0b8soysW+dcszx9Jv01aWD9MVLutem3D1z+fjixQzUeVORCcFDHvS6qUw9Ns1Lcr0TFljcmwxk go5lfQRyYWM7/hJcrnzU6X1tdxzd3oE/+XkPP4ubHAuVBKEo5aA68z1TWzEEU6ipDmXzuPrkAsS z0= X-Received: by 2002:a05:600c:848c:b0:48a:52d4:888c with SMTP id 5b1f17b1804b1-48fe60e5241mr368780515e9.3.1779267069635; Wed, 20 May 2026 01:51:09 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4900c16c62dsm205712165e9.11.2026.05.20.01.51.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 01:51:09 -0700 (PDT) Date: Wed, 20 May 2026 09:51:07 +0100 From: David Laight To: Zong Li Cc: Ron Economos , 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 Message-ID: <20260520095107.1bf48926@pumpkin> In-Reply-To: References: <20260519071809.3823470-1-zong.li@sifive.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 20 May 2026 13:59:44 +0800 Zong Li wrote: > On Tue, May 19, 2026 at 5:20=E2=80=AFPM Zong Li wrot= e: > > > > On Tue, May 19, 2026 at 4:28=E2=80=AFPM Ron Economos wrot= e: =20 > > > > > > On 5/19/26 00:18, Zong Li wrote: =20 > > > > Rationale: > > > > > > > > 1. Shadow stacks only store return addresses (8 bytes per entry), n= ot > > > > local variables, function parameters, or saved registers. A 512= MB > > > > 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 4= GB > > > > 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 allocatio= n" > > > > > > > > Suggested-by: David Laight > > > > Signed-off-by: Zong Li > > > > --- > > > > > > > > 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 b= y David Laight > > > > > > > > Changed in v2: > > > > - Add max() in case RLIMIT_STACK is smaller than PAGE_SIZE. Suggest= ed 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/usercf= i.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 *ta= sk, bool lock) > > > > task->thread_info.user_cfi_state.ufcfi_locked =3D 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 var= iables > > > > + * 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_STA= CK), SZ_4G)); > > > > + return PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 8, SZ_512M)); > > > > } > > > > > > > > /* =20 > > > > > > 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. =20 > > =20 >=20 > 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 >=20 > > 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 > > =20 > > > =20