From nobody Sun May 24 18:42:58 2026 Received: from mail-dl1-f53.google.com (mail-dl1-f53.google.com [74.125.82.53]) (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 343C01367 for ; Fri, 22 May 2026 09:36:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779442602; cv=none; b=mFsopm//yWUpt+rRyAAM4ajvs6TBGf+us+yJb713MOKnUXFYXO0Vvh7eddFevynfOw5rOo9lk42hoC1oYX0S5l4XNys9TD7vlR0uUpC4jBGeb/17RccVPJfU9ln5MEMiZm2ELUgaaWhPyLC5Vk8/Gu764C+rfMxGZlMN78jqVZE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779442602; c=relaxed/simple; bh=jJryzghIDtav9amgjDSovmNA5AK6dE0aSrK99Ow6dZI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=XMfI0QMqCrzvIfnHVJlAusLK28YdD60uSVIQ9W0VUrU5wDR8et5B0G/6Y2FuKqNdc29Kus3JHKDaPnK7KU16+k66rpT46xGOlGwMF/U3UAEColbYfOkTAPq1sXtqkwOtKKyNIlROIpsBK8KoJvaPs2aZXUKjASUOd/127dNcUUQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com; spf=pass smtp.mailfrom=sifive.com; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b=FIKwjBSp; arc=none smtp.client-ip=74.125.82.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sifive.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="FIKwjBSp" Received: by mail-dl1-f53.google.com with SMTP id a92af1059eb24-13663f68983so648692c88.0 for ; Fri, 22 May 2026 02:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1779442600; x=1780047400; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=hqbz0O8aEWGA0yKkRsOUbhxvZ23lpVZ1rZzCE1TMpVs=; b=FIKwjBSpXyi6Cpz9FHPStpHx0XwW3/WwfbtGIhTwrquwD6tLn56bQqw36iwiQyzQRQ 15koC0wxyhkYpr2h8hlVZbqwa7SZjCp3TZdkJlHpvKyfH7/vbNgwBKwXXNRoK6SxW+nw qGiAYYPp4UhLRp9GT0al5tQjekhYgaUGaae5GZiRLqH2ml+TKCe+45TOfnHUqSMlBjiB EiCGPsjJ9yDtLHi98QQOqS1SknxAsa7QbVMFwWm3E09qtP4Ep737x4DtLdujA0dB49xW jD8CqD7h9L+lcLnVUYfhUxYG3sp2Yqwx7SPE77d50BD5hiXosHgB9qt6/Ha2yKXIEifv +vGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779442600; x=1780047400; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hqbz0O8aEWGA0yKkRsOUbhxvZ23lpVZ1rZzCE1TMpVs=; b=pJUfe8CW6sLRhOtHSS3VRsHxUDZbOh/kIYYBoe9YIuOF0ceWhppDE+FuwSNhB15tem /SyDB0TB1nJ8DX8hSTDG0+LNBcGcMcV2baa0riFk7XxmF0KbiDLQBjkoUgh1n8V991EO iRQuuq6u4rRp7pVb9E68TmkkUNmArHqfCK3Va8DsuhOsk4Y3UnxsoQm3W86pofhDMcMF NzNc1WN7SFQnJStifYDFcb38OHFv6lsmc0m7fQWffLbNmVhkP9YouEz1+J5o/HiAbFwe lHtWYCPKiBpG257vR8vSBkb+UOWk2Y8FOAFBXzGTfbDZxagQa5gyKK13uuuQ8ZB6dsr+ zT+g== X-Forwarded-Encrypted: i=1; AFNElJ+5ipb86SYEEOmRKfdr3SOAWqBCg+DCcwRegWl6r3oPrlYaJ6i9TstCHS029r9d67jSMoSBpTe7HPUz1TI=@vger.kernel.org X-Gm-Message-State: AOJu0YwMHDNR2hr/NcWnkxKXx0cjU8cVDT6W4R/md+HBcOD+OjgElaTR z0aW7Af7JRRvj8KAhEVJt4y6dpoRs8QlM+SOplUG308CqMo9wcc1pK/B5CMb21X9A18= X-Gm-Gg: Acq92OFeeA3IUFCJukwuL2LmBntOCGb0rFMFFfsA9sOBealOJtdoe2ywZfilXWdlyfn 1UHnffzAxH1Eg9bW3gb5adxsI45O6Dway662uBiCj4puKx7hk7e28ZL7zwZ8Kd+hROUQBrXh6Kt wfkXFpDufLcgOS9hW2BHZgjC2XjKckW5uvGJfqhzMtsyVrSj64BIxnIQrUmV2pcUxyAY1no6HPM KTYAidDW14Wc3XUYSabIgWAmJ/6CkEf7RCWVFjmG8/N27k0PjJDZPIkUPXpJEtMVLAVgXoEVyck Pms5d2ZA69ahyzbtjqGNb3jYbN+04j1RLivL0lCkUXvRhDx1veuzziPoIkNXAEFZ3nrv8rN7Cl9 Exy2eY060GoXGLGMzjkNOMONrSbmDizBWbUw760h791HBw2zjLweKLT4qo8x+zi3NM7OPeq9Aon 4Z2qzYeJehlCjw0g8Bnz5YjXIoF3QIMPu2hD4= X-Received: by 2002:a05:7022:671f:b0:12b:f616:1a4e with SMTP id a92af1059eb24-1365fa45a25mr993856c88.23.1779442600181; Fri, 22 May 2026 02:36:40 -0700 (PDT) Received: from sw04.internal.sifive.com ([4.53.31.132]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1366a2e672asm801474c88.3.2026.05.22.02.36.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 02:36:39 -0700 (PDT) From: Zong Li To: 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 Cc: Zong Li Subject: [PATCH] riscv: cfi: reduce shadow stack size limit from 2GB to 512MB Date: Fri, 22 May 2026 02:36:34 -0700 Message-ID: <20260522093634.3530233-1-zong.li@sifive.com> X-Mailer: git-send-email @GIT_VERSION@ Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 --- arch/riscv/kernel/usercfi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c index cbfb4e495e9f..adf97426a906 100644 --- a/arch/riscv/kernel/usercfi.c +++ b/arch/riscv/kernel/usercfi.c @@ -110,7 +110,7 @@ void set_indir_lp_lock(struct task_struct *task, bool l= ock) } /* * The shadow stack only stores the return address and not any variables - * this should be more than sufficient for most applications. + * 512M should be more than sufficient for most applications. * Else PAGE_ALIGN it and return back */ static unsigned long calc_shstk_size(unsigned long size) @@ -118,7 +118,7 @@ static unsigned long calc_shstk_size(unsigned long size) if (size) return PAGE_ALIGN(size); =20 - return PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 2, SZ_2G)); + return PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 8, SZ_512M)); } =20 /* --=20 2.43.7