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,
Stian Halseth <stian@itx.no>
Subject: [PATCH v2] sparc64: increase kernel thread stack size to 32K
Date: Mon, 31 Aug 2026 19:29:24 +0200 [thread overview]
Message-ID: <20260831172928.3082853-1-stian@itx.no> (raw)
In-Reply-To: <20260519075809.8993-1-unixpro1970@gmail.com>
From: Tony Rodriguez <unixpro1970@gmail.com>
Kernel stacks on sparc64 are 16K and this is no longer enough:
several machines (SPARC T5-2 among them) 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 on an UltraSPARC T4-1 show the
problem is frame count, not any single large frame. 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 then a timer
interrupt (which runs on the task stack, and whose scheduler tick
performs load balancing and IPI delivery) 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
(128-byte register window save area plus 48-byte argument save
area). 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.
Double THREAD_SIZE to 32K (four 8K pages). The PAGE_SHIFT
conditionals are dropped: sparc64 only supports 8K base pages, so
the other branches were dead code. 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/
Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
[stian: reduced the diff to the THREAD_* defines, measured stack
usage with CONFIG_STACK_TRACER and rewrote the changelog]
Signed-off-by: Stian Halseth <stian@itx.no>
---
v2:
- drop the CONFIG_SPARC64 / PAGE_SHIFT conditional chain from v1;
thread_info_64.h is only built on sparc64 and only 8K pages are
supported, so define the three constants unconditionally
- replace the panic backtrace in the changelog with stack tracer
measurements answering David Laight's review comments:
https://lore.kernel.org/all/20260520144104.618c75ca@pumpkin/
- retitled from "unify thread stack sizing and add explicit 32KB
stack"; the sizing logic for other configurations is unchanged
Tested on an UltraSPARC T4-1, booted with the stack tracer armed
("stacktrace") before and after this patch. The boot high-water mark
is 12616 bytes on both kernels - the worst path (hub_probe with a
printk and a timer interrupt on top) is deterministic - i.e. 77% of
the 16K stack before, 38% of the 32K stack after. DEBUG_STACK_USAGE
agrees: the peak boot-time task shows 9208 bytes left of 16K before
vs 25592 bytes left of 32K after (7176 bytes used in both).
arch/sparc/include/asm/thread_info_64.h | 15 +++------------
1 file changed, 3 insertions(+), 12 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
@@ -99,13 +99,8 @@
#define FAULT_CODE_BLKCOMMIT 0x10 /* Use blk-commit ASI in copy_page */
#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)
-#else /* PAGE_SHIFT == 13 */
-#define THREAD_SIZE PAGE_SIZE
-#define THREAD_SHIFT PAGE_SHIFT
-#endif /* PAGE_SHIFT == 13 */
+#define THREAD_SIZE (4 * PAGE_SIZE)
+#define THREAD_SHIFT (PAGE_SHIFT + 2)
/*
* macros/functions for gaining access to the thread information structure
@@ -128,11 +123,7 @@
#endif
/* thread information allocation */
-#if PAGE_SHIFT == 13
-#define THREAD_SIZE_ORDER 1
-#else /* PAGE_SHIFT == 13 */
-#define THREAD_SIZE_ORDER 0
-#endif /* PAGE_SHIFT == 13 */
+#define THREAD_SIZE_ORDER 2
#define __thread_flag_byte_ptr(ti) \
((unsigned char *)(&((ti)->flags)))
--
2.53.0
next prev parent reply other threads:[~2026-08-31 17:29 UTC|newest]
Thread overview: 20+ 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 ` Stian Halseth [this message]
2026-08-31 18:25 ` [PATCH v2] sparc64: increase kernel thread stack size to 32K 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
[not found] <f3719bb0-e892-49cc-af82-79e2569a8a90@gmail.com>
2026-08-31 19:04 ` Tony Rodriguez
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=20260831172928.3082853-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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.