Re: [PATCH v2] sparc64: increase kernel thread stack size to 32K

[Stian Halseth]

Hi Tony, 

You're welcome. 

I saw it was stuck, and wanted to push it along. Looks to me like a
proper fix that should be included.

PS: Don't want to take any credit, this is 100% your fix. If you rather
want to handle it yourself, let me know :)

-- 
Best regards
Stian Halseth



On Mon, 2026-08-31 at 11:25 -0700, Tony Rodriguez wrote:
> 
> When I compile the kernel with -fstack-usage to generate .su files,
> on 
> 7.1 kerner, the static analysis shows small stack frames for all USB 
> core functions.
> For example:
> 
> hub_event:      2457 bytes  (static)
> hub_activate:   1892 bytes  (static)
> usb_control_msg: 1248 bytes (static)
> 
> However, my runtime stack tracing shows a dramatically different
> picture:
> 
> STACKTRACE: hub_event():entry: 31856 bytes used
> STACKTRACE: hub_activate():entry: 31680 bytes used
> STACKTRACE: usb_control_msg():entry: 30768 bytes used
> 
I'm not quite sure what I'm looking at. Stack usage must _increase_
with call depth, but looks like it's decreasing?

That shouldn't be possible, but maybe I'm misreading something?

It kinda looks like you're showing sp - stack_base (space left). 

CONFIG_STACK_TRACER on the T4-1 measures 12.6K worst-case against 32K.
Could you re-measure with stacktrace on the kernel command line? 
Happy to share the exact config/procedure.
> 
> PS - I have not tested a 64K stack yet, only 32K, and this is a
> heads-up 
> recommendation.
> 
> 
> Tony
> 
> On 8/31/26 10:29 AM, Stian Halseth wrote:
> > From: Tony Rodriguez <unixpro1970@xxxxxxxxx>
> > 
> > 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@xxxxxxxxx/
> > Signed-off-by: Tony Rodriguez <unixpro1970@xxxxxxxxx>
> > [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@xxxxxx>
> > ---
> > 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