Re: netpoll: raspberrypi [4 5] driver locking woes

Hi Mike,

On 8/27/25 12:02, Mike Galbraith wrote:

Unexpected addendum to done deal datapoint, so off list.

On Tue, 2025-08-26 at 11:49 +0200, Mike Galbraith wrote:

quoted

The pi5 gripe fix is equally trivial, but submitting that is pointless
given there's something else amiss in fingered commit.  This is all of
the crash info that escapes the box w/wo gripes silenced.

[   51.688868] sysrq: Trigger a crash
[   51.688892] Kernel panic - not syncing: sysrq triggered crash
[   51.698066] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.17.0-rc2-v8-lockdep #533 PREEMPTLAZY
[   51.707234] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
[   51.713085] Call trace:
[   51.715532]  show_stack+0x20/0x38 (C)
[   51.719206]  dump_stack_lvl+0x38/0xd0
[   51.722878]  dump_stack+0x18/0x28

That aspect is a punt and run atm (time.. and dash of laziness:).

Plan was to end datapoint thread, but after booting pi5's 6.12 kernel,
for some reason I fired up netconsole.. and box promptly exhibited the
netpoll locking bug warning, indicating presence of 138badbc21a0. 
Instead of saying to self "nope, just walk away", I poked SysRq-C.. and
the bloody damn monitoring box received a 100% complete death rattle. 
Well bugger.

Did you get a backtrace for this?

And to be clear, the steps to reproduce this are to boot a kernel with
lockdep enabled with netconsole on macb and then hit sysrq?

Two trees contain locking buglet introducing 138badbc21a0, 6.12.41 and
6.17.0, but only the later reproduces the above mess.  A quick stare at
git diff inspired checking e6a532185daa, and sure enough reverting only
it reproduced a functional netconsole, modulo warnings, ie the mess
above manifests only with BOTH resident.  Either revert 138badbc21a0,
or revert e6a532185daa and fix the 138badbc21a0 locking buglet, and the
result is the same, a perfectly functional warning free netconsole.