Re: [syzbot] [kernel?] WARNING in _cpu_down

[Daniel Jordan]

On Wed, Mar 11, 2026 at 12:45:33PM -0400, Daniel Jordan wrote:
> 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.

Potential fix is here:
    https://lore.kernel.org/all/20260312172959.471272-1-daniel.m.jordan@xxxxxxxxxx/