mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®