Re: [syzbot] [kernel?] WARNING in _cpu_down
From: Daniel Jordan
Date: Wed Mar 11 2026 - 12:47:57 EST
On Wed, Mar 11, 2026 at 08:56:36AM +0100, Thomas Gleixner wrote:
> On Mon, Mar 09 2026 at 10:57, syzbot wrote:
> > syzbot found the following issue on:
> >
> > HEAD commit: 4ae12d8bd9a8 Merge tag 'kbuild-fixes-7.0-2' of git://git.k..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=177cca02580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=163cf0fb07ea84d3
> > dashboard link: https://syzkaller.appspot.com/bug?extid=123e1b70473ce213f3af
> > compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > smpboot: CPU 1 is now offline
> > smpboot: Booting Node 0 Processor 1 APIC 0x1
> > ------------[ cut here ]------------
> > DEAD callback error for CPU1
> > WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614
>
> That means one of the hotplug state callbacks which are issued after a
> CPU is dead returned an error. That's wrong. Those callbacks are not
> supposed to fail as there is no way to rollback at that point.
>
> A quick coccinelle search finds exactly one callback in that stage which
> might return an error code:
>
> padata_cpu_dead()
>
> Not sure how to fix that. I leave it to the padata folks ...
CPUHP_PADATA_DEAD can go away entirely, and padata's callback from the
ONLINE section of hotplug can take care of teardown instead, the way it
used to before CPUHP_PADATA_DEAD got added. That way the failure will
be allowed to happen.
It's memory allocation that might fail, and it's harder to avoid the
allocations than to move the callback to a different part of the hotplug
state machine.
I'll try it out.