From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f173.google.com (mail-dy1-f173.google.com [74.125.82.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E66A73A9639 for ; Tue, 19 May 2026 23:57:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779235029; cv=none; b=lfUqDgQYvB+oayP3lNz0K0BDAuJuRdIvwRe735oN4tiaYGJ6q+2S6rCSFbuYnxdXGVAThPYh3xnXX7mA0iJTfl7N6OgzB9rZUPcQlwWnyMg9+Xl39znkBcnoS8HYQ6AElkrcT0kMW4wdSwcmy5c4slNF9AUoW6QRJIJlbhju/h8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779235029; c=relaxed/simple; bh=s+3OhO8jaiv4gp4W2MmMu1vTmS+Aqx0YsvRWaoIeR9U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=msA689yW2DIcJUGIyz8ps+/NkGeE+0hcUi/dur2zQ+O6mm37xno+BvfAxGyV/QcObMHkrCcmqRG6899Q1uhMvtBeDaOUNJMbEhkn0GmgVLlgLxvFq6IIzS4px0WXzRA14x1s11RmbJ22fk5YREcWMXJE/HOI7aeBOh7pj3whkwc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=a87O32tl; arc=none smtp.client-ip=74.125.82.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="a87O32tl" Received: by mail-dy1-f173.google.com with SMTP id 5a478bee46e88-2ee990e8597so10960209eec.1 for ; Tue, 19 May 2026 16:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779235026; x=1779839826; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KwVNzBda9+o6BwkcgCejimTHlfEURUsk3PVURqJTo84=; b=a87O32tlOK17uO+m4T3LC33csKERnF8IFn/bN0Y7nR/bel8amFKiW56WB4EjLulu/M E3FDZebp0GEj9ekFLZhuyyrulk7GcA77laPjSiry3Rj+NymvUHEak5VrM1GRzzkq8DJV 9veFPA0T8lVzlriCps5SH1cUI+1zTDjsLwstr/zO3q7rCHQbmsKvI7Oa+E49dIQhCq2u IL0oGuLnk58Z3LV+wF40UYMHATHy1XlToQJNgTG8q1U5FILYF0mGaSRHAi6PwGyOeuhW K+YAppcoAF3+2QrkvbAsdOPmg0mOywqSZR6UR+4f1zRf+nMdJxGc1WB5groEVCo8/5O9 sV8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779235026; x=1779839826; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KwVNzBda9+o6BwkcgCejimTHlfEURUsk3PVURqJTo84=; b=Flu46wHixH6Y8mMA1BFGagDHcKDHYH9OU3RoJerEdLiEc5Pgy4XXGS0+sL+8eO/FMK hGUgBfymJ5ZuI2TaR1VTFHw1jIFMy93BvLA9QjyDDnbJcW1Q6FMXeEqoRTOdvmpc+zRA 0UOZaI6+JxSu23GmJK/ixtPMTeHeEeMgpPXc2ryQki+9QXkXwgMqQ0o6lpTqAMuXLn/7 rDmRkrGiPQm6g1h3X7Ia4EacDZllerOVbUuaDIt4p+99m6ChkJPFlu1HnwpzWFvBpaR9 6O3XQ0GBeTsN7OzcutMOVn82pdAwZSPkI0fnVrhZf09IYZfD5OX41ci3t+uF+3dBlAoi Uu1g== X-Forwarded-Encrypted: i=1; AFNElJ87k/xVOtlZNeyqbtgw0IqlDgRRe7uyKTH0Rh1tbxQo+26cXXTIW7ryXazYI5tfLK//ACLqvhWJ/kAdE04=@vger.kernel.org X-Gm-Message-State: AOJu0Yy4ImkGU4sH4uSbuSEWUI8WSX6RXNLpEDOljzLRxznXC7LzQMGu QKwIEnmJ7kK4ntqHgxcj+8ezIVBSP0vT/sDNoUGthHL/j5Gmd2wPqR79 X-Gm-Gg: Acq92OFB/H3F5uLXm2W//4ic1pptx32DCLE5/3GYDtfJeFeg9+GqpdOdRbL//QUsFeb YkPHDsrhf/YwYMMEC+vT7LH4o7arujjhdAXkQiYvTkKOzjIexIwCNS+P+o8IZIxI1pIcxAGmAql KTH3umc0hAX6iXFZJ5qGv/q+hWVWk91mEgam9tM/SEn5saiENd3AZx0TGQ3csdHGSvd1Ch0YoiH LIHGb7rWFAWHuRgyoSYz1x7YCP7W+TMBwuYkgUyjxiu96ISlJqRyrXqb1IAZI2e9Dreq1XYka52 1viGAaNv2e7Esu3rG93wHXIL7rnFxYN+CGNjK7pL4m4YCoYcshoJaNzW/JhO1hthB91ofB1NSDb yq/RLaQc3eVd6aTMSdr/UEGAxHLE0773QXQYX+83KOZSGalsFLV4tr/yMcHYWElZOGLc/Y3aKwF WAbdRdgQ5LMJYWcWeMJblGCU7gQ86UqQ== X-Received: by 2002:a05:7300:a286:b0:2f1:6252:f8fe with SMTP id 5a478bee46e88-303981914a5mr9989210eec.3.1779235026049; Tue, 19 May 2026 16:57:06 -0700 (PDT) Received: from [192.168.21.192] ([67.170.89.46]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-304052f79ecsm3305232eec.11.2026.05.19.16.57.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 May 2026 16:57:05 -0700 (PDT) Message-ID: <05e0e7a5-107b-410b-853b-883810b1be3e@gmail.com> Date: Tue, 19 May 2026 16:57:04 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Betterbird (Linux) Subject: Re: [PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack Content-Language: en-US To: David Laight Cc: davem@davemloft.net, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, andreas@gaisler.com, thuth@redhat.com, regressions@lists.linux.dev, glaubitz@physik.fu-berlin.de References: <20260519075809.8993-1-unixpro1970@gmail.com> <20260519110223.5aeb88e3@pumpkin> From: Tony Rodriguez In-Reply-To: <20260519110223.5aeb88e3@pumpkin> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/19/26 3:02 AM, David Laight wrote: > On Tue, 19 May 2026 00:57:54 -0700 > Tony Rodriguez 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 >> >> >> 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 >> >>