From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D7E3271456 for ; Tue, 14 Jul 2026 02:47:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783997251; cv=none; b=F4Kdebq0oVMOBE7gCda/YhbS4e7LMjAqnTOUhOR2td5flex79ag+DLinabtdxmMk8PVElUmtOFeDID9z6dvrnUljtAoG1yGZZLGUr67wiT6PIjgIjt8+SOQneMmb36Jc/e5Y89OUjZZ5jmTGz9I7hdbDehP0FTaWeaVD05olmbs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783997251; c=relaxed/simple; bh=JhInhJFFmt+IW+yrVXtwz5PpcJoHYjNwUt1dWu6balY=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=j0YjA11kYaPj72aCsFH9HeCHtefazpNxoYUEaEgKgNjillV0BoDt4Z+J+O55+QrpiM3Lculj2nZ+n8yqMeAdFPBv9ulKi5P2GrNfBxQEDLwM/GpVU41319Jcgt7OFn1YZzkl/tMi+LFxYXVOZh7pABxijukVwnljsjA1/NtHoqk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ErtBlSxb; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ErtBlSxb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33B821F000E9; Tue, 14 Jul 2026 02:47:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783997249; bh=0fceUV7xDfsTEP1Ag2cwz/O1er8mo7XMPjMZGcxSXxs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ErtBlSxbFig77uXtMf621X5RdDuRhWHUjt7hMOeHELxQxcisQ5B/fYECZ1XjExqvd VIQGSA3EkKwddqOWsvHLC6SmRQEML8KXEwW+8azzvsq2dZ04SLaNFXG+GTO4qK4OF/ C6y79nlvshfE/q+juch3XG3CA8qwG4N2lGevwaT7H0fOzG05QBtXCjHEYZlu20lj+d TPczDJOC5DwThg8S6EgGn+bxgY8QQGhE80rC02dojEzThnOA4R8vvhIJQEMo3ylOHH 8VuXFAMd2Px4+5PgFhW25et6i4tFgHlmOxfcftPRH00jDqrYtOeZMach13d9HAPW7r XZICD16Dukfmw== Date: Mon, 13 Jul 2026 20:47:28 -0600 (MDT) From: Paul Walmsley To: Zong Li 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, david.laight.linux@gmail.com, re@w6rz.net Subject: Re: [PATCH] riscv: cfi: reduce shadow stack size limit from 2GB to 512MB In-Reply-To: <20260522093634.3530233-1-zong.li@sifive.com> Message-ID: References: <20260522093634.3530233-1-zong.li@sifive.com> 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=US-ASCII On Fri, 22 May 2026, Zong Li wrote: > Change the shadow stack size calculation from RLIMIT_STACK/2 (capped at > 2GB) to RLIMIT_STACK/8 (capped at 512MB), following David Laight's > analysis and recommendation. > > Rationale: > > David Laight pointed out that the focus should be on the ratio between > shadow stack size and the normal stack size, rather than just the > absolute upper limit. His analysis showed that while there are many > functions with small stack frames, the majority have stack deltas of > over 64 bytes due to saved registers and local variables. > > Shadow stacks only store return addresses (8 bytes per entry on 64-bit > systems), whereas normal stack frames typically consume 64+ bytes. This > 8:64 byte ratio means that programs using a lot of stack space are > dominated by large buffer allocations and local variables, not extreme > recursion depths with minimal local data. > > For example, with the default RLIMIT_STACK of 8MB: > - RLIMIT_STACK/2 gives a 4MB shadow stack supporting 512K nested calls > - RLIMIT_STACK/8 gives a 1MB shadow stack supporting 128K nested calls > > Given typical stack frame sizes of 64+ bytes, RLIMIT_STACK/8 is still > conservative and provides adequate depth for practical applications. > David noted that this could even be safely halved again. > > This reduction also better accommodates memory-constrained platforms. > On systems with limited physical memory, allocating large shadow stacks > can cause virtual memory allocation failures when overcommit mode is set > to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER. > > Suggested-by: David Laight > Link: https://lore.kernel.org/all/20260518105725.7afe7a4c@pumpkin/ > Signed-off-by: Zong Li Thanks, queued for v7.3. - Paul