1. Patchew
  2. linux
  3. View series

[PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack

Tony Rodriguez posted 1 patch 5 days, 18 hours ago 
arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
1 file changed, 14 insertions(+), 14 deletions(-)
[PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack
Posted by Tony Rodriguez 5 days, 18 hours ago 
This patch fixes a reproducible stack exhaustion issue on SPARC64
that occurs during USB hub enumeration. This regression may have
started sometime after kernel v6.12. With the default 16KB kernel
stack, the following panic is triggered early in boot:

    [   25.528399] Call Trace:
    [   25.528403] [<0000000000433cd4>] dump_stack+0x8/0x18
    [   25.528419] [<00000000004297ac>] vpanic+0xdc/0x318
    [   25.528429] [<0000000000429a0c>] panic+0x24/0x30
    [   25.528436] [<0000000000be2280>] __schedule+0xa8/0x7bc
    [   25.528445] [<0000000000be2b60>] schedule+0x24/0x4c
    [   25.528452] [<0000000000be6970>] schedule_timeout+0xc8/0xe4
    [   25.528459] [<0000000000be3318>] __wait_for_common+0x78/0xf0
    [   25.528466] [<0000000000be3550>] wait_for_completion_timeout+0x1c/0x2c
    [   25.528473] [<000000001005e2f4>] usb_start_wait_urb+0x68/0x128 [usbcore]
    [   25.528502] [<000000001005e468>] usb_control_msg+0xb4/0xf8 [usbcore]
    [   25.528518] [<0000000010051180>] set_port_feature+0x44/0x54 [usbcore]
    [   25.528530] [<00000000100530f0>] hub_power_on+0xc8/0xe8 [usbcore]
    [   25.528543] [<0000000010054fd8>] hub_activate+0x12c/0x644 [usbcore]
    [   25.528557] [<0000000010059438>] hub_probe+0xdd4/0xeb0 [usbcore]
    [   25.528570] [<0000000010062360>] usb_probe_interface+0x234/0x26c [usbcore]
    [   25.528585] [<0000000000a10a40>] really_probe+0x1ac/0x3b0

This is caused by large SPARC64 trapframes, register-window spills,
and deep call paths in usbcore. A 16KB stack is insufficient for
this workload.

The new logic is:

    SPARC64:
        THREAD_SIZE = 4 * PAGE_SIZE (32KB)
        THREAD_SHIFT = PAGE_SHIFT + 2
        THREAD_SIZE_ORDER = 2

    Non‑SPARC64 with PAGE_SHIFT == 13:
        Retains the existing 16KB stack behavior

    Fallback:
        Retains the existing 8KB stack behavior

Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>


Tony Rodriguez (1):
  sparc64: unify thread stack sizing and add explicit 32KB stack

 arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
 1 file changed, 14 insertions(+), 14 deletions(-)

--
2.53.0
Re: [PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack
Posted by David Laight 5 days, 16 hours ago 
On Tue, 19 May 2026 00:57:54 -0700
Tony Rodriguez <unixpro1970@gmail.com> wrote:

> This patch fixes a reproducible stack exhaustion issue on SPARC64
> that occurs during USB hub enumeration. This regression may have
> started sometime after kernel v6.12. With the default 16KB kernel
> stack, the following panic is triggered early in boot:
> 
>     [   25.528399] Call Trace:
>     [   25.528403] [<0000000000433cd4>] dump_stack+0x8/0x18
>     [   25.528419] [<00000000004297ac>] vpanic+0xdc/0x318
>     [   25.528429] [<0000000000429a0c>] panic+0x24/0x30
>     [   25.528436] [<0000000000be2280>] __schedule+0xa8/0x7bc
>     [   25.528445] [<0000000000be2b60>] schedule+0x24/0x4c
>     [   25.528452] [<0000000000be6970>] schedule_timeout+0xc8/0xe4
>     [   25.528459] [<0000000000be3318>] __wait_for_common+0x78/0xf0
>     [   25.528466] [<0000000000be3550>] wait_for_completion_timeout+0x1c/0x2c
>     [   25.528473] [<000000001005e2f4>] usb_start_wait_urb+0x68/0x128 [usbcore]
>     [   25.528502] [<000000001005e468>] usb_control_msg+0xb4/0xf8 [usbcore]
>     [   25.528518] [<0000000010051180>] set_port_feature+0x44/0x54 [usbcore]
>     [   25.528530] [<00000000100530f0>] hub_power_on+0xc8/0xe8 [usbcore]
>     [   25.528543] [<0000000010054fd8>] hub_activate+0x12c/0x644 [usbcore]
>     [   25.528557] [<0000000010059438>] hub_probe+0xdd4/0xeb0 [usbcore]
>     [   25.528570] [<0000000010062360>] usb_probe_interface+0x234/0x26c [usbcore]
>     [   25.528585] [<0000000000a10a40>] really_probe+0x1ac/0x3b0
> 
> This is caused by large SPARC64 trapframes, register-window spills,
> and deep call paths in usbcore. A 16KB stack is insufficient for
> this workload.

Increasing the stack size for all threads seems overkill.
That stack doesn't even look deep.
I suspect there are large on-stack buffers in there.

Unfortunately the traceback doesn't print the stack pointers making
debugging hard.

-- David

> 
> The new logic is:
> 
>     SPARC64:
>         THREAD_SIZE = 4 * PAGE_SIZE (32KB)
>         THREAD_SHIFT = PAGE_SHIFT + 2
>         THREAD_SIZE_ORDER = 2
> 
>     Non‑SPARC64 with PAGE_SHIFT == 13:
>         Retains the existing 16KB stack behavior
> 
>     Fallback:
>         Retains the existing 8KB stack behavior
> 
> Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
> 
> 
> Tony Rodriguez (1):
>   sparc64: unify thread stack sizing and add explicit 32KB stack
> 
>  arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> --
> 2.53.0
> 
>
Re: [PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack
Posted by Tony Rodriguez 5 days, 2 hours ago 
On 5/19/26 3:02 AM, David Laight wrote:
> On Tue, 19 May 2026 00:57:54 -0700
> Tony Rodriguez <unixpro1970@gmail.com> wrote:
>
>> This patch fixes a reproducible stack exhaustion issue on SPARC64
>> that occurs during USB hub enumeration. This regression may have
>> started sometime after kernel v6.12. With the default 16KB kernel
>> stack, the following panic is triggered early in boot:
>>
>>      [   25.528399] Call Trace:
>>      [   25.528403] [<0000000000433cd4>] dump_stack+0x8/0x18
>>      [   25.528419] [<00000000004297ac>] vpanic+0xdc/0x318
>>      [   25.528429] [<0000000000429a0c>] panic+0x24/0x30
>>      [   25.528436] [<0000000000be2280>] __schedule+0xa8/0x7bc
>>      [   25.528445] [<0000000000be2b60>] schedule+0x24/0x4c
>>      [   25.528452] [<0000000000be6970>] schedule_timeout+0xc8/0xe4
>>      [   25.528459] [<0000000000be3318>] __wait_for_common+0x78/0xf0
>>      [   25.528466] [<0000000000be3550>] wait_for_completion_timeout+0x1c/0x2c
>>      [   25.528473] [<000000001005e2f4>] usb_start_wait_urb+0x68/0x128 [usbcore]
>>      [   25.528502] [<000000001005e468>] usb_control_msg+0xb4/0xf8 [usbcore]
>>      [   25.528518] [<0000000010051180>] set_port_feature+0x44/0x54 [usbcore]
>>      [   25.528530] [<00000000100530f0>] hub_power_on+0xc8/0xe8 [usbcore]
>>      [   25.528543] [<0000000010054fd8>] hub_activate+0x12c/0x644 [usbcore]
>>      [   25.528557] [<0000000010059438>] hub_probe+0xdd4/0xeb0 [usbcore]
>>      [   25.528570] [<0000000010062360>] usb_probe_interface+0x234/0x26c [usbcore]
>>      [   25.528585] [<0000000000a10a40>] really_probe+0x1ac/0x3b0
>>
>> This is caused by large SPARC64 trapframes, register-window spills,
>> and deep call paths in usbcore. A 16KB stack is insufficient for
>> this workload.
> Increasing the stack size for all threads seems overkill.
> That stack doesn't even look deep.
> I suspect there are large on-stack buffers in there.
>
> Unfortunately the traceback doesn't print the stack pointers making
> debugging hard.
>
> -- David

Hi David. Any specific grub command line keywords and values, and 
functions you recommend for debugging this?  I would be happy to share 
Trace Calls, etc. so it is easier to reconfirm and zero in on the issue. 
-- Tony

>> The new logic is:
>>
>>      SPARC64:
>>          THREAD_SIZE = 4 * PAGE_SIZE (32KB)
>>          THREAD_SHIFT = PAGE_SHIFT + 2
>>          THREAD_SIZE_ORDER = 2
>>
>>      Non‑SPARC64 with PAGE_SHIFT == 13:
>>          Retains the existing 16KB stack behavior
>>
>>      Fallback:
>>          Retains the existing 8KB stack behavior
>>
>> Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
>>
>>
>> Tony Rodriguez (1):
>>    sparc64: unify thread stack sizing and add explicit 32KB stack
>>
>>   arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
>>   1 file changed, 14 insertions(+), 14 deletions(-)
>>
>> --
>> 2.53.0
>>
>>
Re: [PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack
Posted by David Laight 4 days, 13 hours ago 
On Tue, 19 May 2026 16:57:04 -0700
Tony Rodriguez <unixpro1970@gmail.com> wrote:

> On 5/19/26 3:02 AM, David Laight wrote:
> > On Tue, 19 May 2026 00:57:54 -0700
> > Tony Rodriguez <unixpro1970@gmail.com> wrote:
> >  
> >> This patch fixes a reproducible stack exhaustion issue on SPARC64
> >> that occurs during USB hub enumeration. This regression may have
> >> started sometime after kernel v6.12. With the default 16KB kernel
> >> stack, the following panic is triggered early in boot:
> >>
> >>      [   25.528399] Call Trace:
> >>      [   25.528403] [<0000000000433cd4>] dump_stack+0x8/0x18
> >>      [   25.528419] [<00000000004297ac>] vpanic+0xdc/0x318
> >>      [   25.528429] [<0000000000429a0c>] panic+0x24/0x30
> >>      [   25.528436] [<0000000000be2280>] __schedule+0xa8/0x7bc
> >>      [   25.528445] [<0000000000be2b60>] schedule+0x24/0x4c
> >>      [   25.528452] [<0000000000be6970>] schedule_timeout+0xc8/0xe4
> >>      [   25.528459] [<0000000000be3318>] __wait_for_common+0x78/0xf0
> >>      [   25.528466] [<0000000000be3550>] wait_for_completion_timeout+0x1c/0x2c
> >>      [   25.528473] [<000000001005e2f4>] usb_start_wait_urb+0x68/0x128 [usbcore]
> >>      [   25.528502] [<000000001005e468>] usb_control_msg+0xb4/0xf8 [usbcore]
> >>      [   25.528518] [<0000000010051180>] set_port_feature+0x44/0x54 [usbcore]
> >>      [   25.528530] [<00000000100530f0>] hub_power_on+0xc8/0xe8 [usbcore]
> >>      [   25.528543] [<0000000010054fd8>] hub_activate+0x12c/0x644 [usbcore]
> >>      [   25.528557] [<0000000010059438>] hub_probe+0xdd4/0xeb0 [usbcore]
> >>      [   25.528570] [<0000000010062360>] usb_probe_interface+0x234/0x26c [usbcore]
> >>      [   25.528585] [<0000000000a10a40>] really_probe+0x1ac/0x3b0
> >>
> >> This is caused by large SPARC64 trapframes, register-window spills,
> >> and deep call paths in usbcore. A 16KB stack is insufficient for
> >> this workload.  
> > Increasing the stack size for all threads seems overkill.
> > That stack doesn't even look deep.
> > I suspect there are large on-stack buffers in there.
> >
> > Unfortunately the traceback doesn't print the stack pointers making
> > debugging hard.
> >
> > -- David  
> 
> Hi David. Any specific grub command line keywords and values, and 
> functions you recommend for debugging this?  I would be happy to share 
> Trace Calls, etc. so it is easier to reconfirm and zero in on the issue. 

Without the stack offsets from the dump, look at the stack frame sizes
for the functions in that traceback.
I suspect there are too many that get near the compile-time threshold.

-- David

> -- Tony
> 
> >> The new logic is:
> >>
> >>      SPARC64:
> >>          THREAD_SIZE = 4 * PAGE_SIZE (32KB)
> >>          THREAD_SHIFT = PAGE_SHIFT + 2
> >>          THREAD_SIZE_ORDER = 2
> >>
> >>      Non‑SPARC64 with PAGE_SHIFT == 13:
> >>          Retains the existing 16KB stack behavior
> >>
> >>      Fallback:
> >>          Retains the existing 8KB stack behavior
> >>
> >> Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
> >>
> >>
> >> Tony Rodriguez (1):
> >>    sparc64: unify thread stack sizing and add explicit 32KB stack
> >>
> >>   arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
> >>   1 file changed, 14 insertions(+), 14 deletions(-)
> >>
> >> --
> >> 2.53.0
> >>
> >>  
>

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.