From: Stian Halseth <stian@itx.no>
To: andreas@gaisler.com, davem@davemloft.net, sparclinux@vger.kernel.org
Cc: Tony Rodriguez <unixpro1970@gmail.com>,
linux-kernel@vger.kernel.org, david.laight.linux@gmail.com,
glaubitz@physik.fu-berlin.de, thuth@redhat.com,
regressions@lists.linux.dev, nroach44@nroach44.id.au,
kaloz@kernel.org, Stian Halseth <stian@itx.no>
Subject: [PATCH v3 1/2] sparc64: increase kernel thread stack size to 32K
Date: Sun, 27 Sep 2026 23:29:00 +0200 [thread overview]
Message-ID: <20260927212913.3237082-1-stian@itx.no> (raw)
In-Reply-To: <20260927204912.3667-1-kaloz@kernel.org>
From: Tony Rodriguez <unixpro1970@gmail.com>
Kernel stacks on sparc64 are 16K and this is no longer enough:
several machines (SPARC T5-2, Sun Ultra 45) panic early in boot
during USB hub enumeration with "corrupted stack end detected inside
scheduler". sparc has not been converted to THREAD_INFO_IN_TASK, so
thread_info sits at the bottom of the kernel stack and a marginal
overflow corrupts it first; CONFIG_SCHED_STACK_END_CHECK then fires
from __schedule long after the deep path has unwound, which is why
the reported backtraces look shallow.
Measurements with CONFIG_STACK_TRACER show the problem is frame
count, not any single large frame. On an UltraSPARC T4-1 the
high-water mark of an ordinary successful boot is 12616 of 16384
bytes (77%), reached in hub_probe() with a printk console flush and
a timer interrupt (which runs on the task stack) stacked on top. Of
the 66 frames in that path the largest is 408 bytes, and ~85% of
them are 176-224 bytes - at or just above the SPARC V9 ABI minimum
frame. An equivalent call chain on x86-64 costs roughly a third of
the stack, so a 16K stack on sparc64 provides far less effective
call depth than on other 64-bit architectures. On a Sun Ultra 45
(sun4u), which panics on 10 out of 10 boots with 16K stacks and USB
devices attached, a forced hub rebind peaks at 15832 bytes.
Double THREAD_SIZE to 32K (four 8K pages). Kernel stacks become
order-2 allocations; sparc64 has no VMAP_STACK, but stacks are
allocated once per thread and the trade against boot-time panics is
a good one.
Link: https://lore.kernel.org/all/20260519075809.8993-1-unixpro1970@gmail.com/
Tested-by: Imre Kaloz <kaloz@kernel.org> # Sun Ultra 45
Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
[stian: reduced to the minimal value change, measured stack usage]
Signed-off-by: Stian Halseth <stian@itx.no>
---
v3:
- split per Andreas' review of v1: this patch is now only the size
change (minimal diff as posted by Imre Kaloz); the removal of the
dead non-8K-page branches moves to patch 2/2 with a Fixes: tag
for 15b9350a177b
- added Imre's Tested-by and Ultra 45 (sun4u) measurements
v2: https://lore.kernel.org/all/20260831172928.3082853-1-stian@itx.no/
arch/sparc/include/asm/thread_info_64.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/sparc/include/asm/thread_info_64.h b/arch/sparc/include/asm/thread_info_64.h
--- a/arch/sparc/include/asm/thread_info_64.h
+++ b/arch/sparc/include/asm/thread_info_64.h
@@ -100,8 +100,8 @@
#define FAULT_CODE_BAD_RA 0x20 /* Bad RA for sun4v */
#if PAGE_SHIFT == 13
-#define THREAD_SIZE (2*PAGE_SIZE)
-#define THREAD_SHIFT (PAGE_SHIFT + 1)
+#define THREAD_SIZE (4*PAGE_SIZE)
+#define THREAD_SHIFT (PAGE_SHIFT + 2)
#else /* PAGE_SHIFT == 13 */
#define THREAD_SIZE PAGE_SIZE
#define THREAD_SHIFT PAGE_SHIFT
@@ -129,7 +129,7 @@
/* thread information allocation */
#if PAGE_SHIFT == 13
-#define THREAD_SIZE_ORDER 1
+#define THREAD_SIZE_ORDER 2
#else /* PAGE_SHIFT == 13 */
#define THREAD_SIZE_ORDER 0
#endif /* PAGE_SHIFT == 13 */
--
2.53.0
next prev parent reply other threads:[~2026-09-27 21:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 7:57 [PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack Tony Rodriguez
2026-05-19 7:57 ` [PATCH 1/1] " Tony Rodriguez
2026-05-19 8:56 ` Nathaniel Roach
2026-06-16 14:18 ` Andreas Larsson
2026-06-16 19:58 ` David Laight
2026-06-18 5:53 ` Andreas Larsson
2026-06-18 7:29 ` Tony Rodriguez
2026-06-18 8:57 ` David Laight
2026-06-18 10:32 ` David Laight
2026-05-19 10:02 ` [PATCH 0/1] " David Laight
2026-05-19 23:57 ` Tony Rodriguez
2026-05-20 13:41 ` David Laight
2026-08-31 17:27 ` Stian Halseth
2026-08-31 17:29 ` [PATCH v2] sparc64: increase kernel thread stack size to 32K Stian Halseth
2026-08-31 18:25 ` Tony Rodriguez
2026-08-31 18:54 ` Stian Halseth
2026-08-31 20:18 ` Tony Rodriguez
2026-08-31 21:05 ` Stian Halseth
2026-09-02 3:30 ` Tony Rodriguez
2026-09-11 7:13 ` Stian Halseth
2026-09-27 20:49 ` Imre Kaloz
2026-09-27 21:29 ` Stian Halseth [this message]
2026-09-27 21:29 ` [PATCH v3 2/2] sparc64: remove dead THREAD_SIZE branches for non-8K pages Stian Halseth
2026-09-27 21:30 ` [PATCH v2] sparc64: increase kernel thread stack size to 32K Stian Halseth
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=20260927212913.3237082-1-stian@itx.no \
--to=stian@itx.no \
--cc=andreas@gaisler.com \
--cc=davem@davemloft.net \
--cc=david.laight.linux@gmail.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=kaloz@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nroach44@nroach44.id.au \
--cc=regressions@lists.linux.dev \
--cc=sparclinux@vger.kernel.org \
--cc=thuth@redhat.com \
--cc=unixpro1970@gmail.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
all inboxes | Powered by JetHome®