Subject: Re: [syzbot] [kernel?] WARNING: ODEBUG bug in smpboot_thread_fn

From: Ido Schimmel <[email-masked]>
Date: Sun, 10 May 2026 14:15:30 +0300

On Thu, May 07, 2026 at 08:30:10PM +0300, Ido Schimmel wrote:
> On Thu, May 07, 2026 at 10:57:04AM +0200, Thomas Gleixner wrote:
> > On Wed, May 06 2026 at 18:29, Thomas Gleixner wrote:
> > > On Mon, May 04 2026 at 05:23, syzbot wrote:
> > >>
> > >> ------------[ cut here ]------------
> > >> ODEBUG: free active (active state 0) object: ffff888033a47278 object type: timer_list hint: br_ip6_multicast_port_query_expired+0x0/0x380 net/bridge/br_multicast.c:-1
> > >
> > >                                                                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > An object which contains an active timer is RCU freed....
> > 
> > Unlike the other timer in the same object, the own_query timer is not
> > shut down in br_multicast_port_ctx_deinit()
> > 
> > Something kike the below.
> > 
> > Thanks,
> > 
> >         tglx
> > ---
> > --- a/net/bridge/br_multicast.c
> > +++ b/net/bridge/br_multicast.c
> > @@ -2030,8 +2030,10 @@ void br_multicast_port_ctx_deinit(struct
> >  
> >  #if IS_ENABLED(CONFIG_IPV6)
> >  	timer_delete_sync(&pmctx->ip6_mc_router_timer);
> > +	timer_delete_sync(&pmctx->ip6_own_query_timer);
> >  #endif
> >  	timer_delete_sync(&pmctx->ip4_mc_router_timer);
> > +	timer_delete_sync(&pmctx->ip4_own_query_timer);
> >  
> >  	spin_lock_bh(&br->multicast_lock);
> >  	del |= br_ip6_multicast_rport_del(pmctx);
> 
> Thanks for the report and the fix. It looks correct, but it's unclear to
> me which commit to blame.
> 
> AFAICT, the trace tells us that the timer is pending (not executing)
> when the object that contains it is RCU freed. However, it shouldn't be
> possible for the timer to be pending at this stage since it is
> deactivated when the port multicast context is disabled and it is only
> reactivated if the context is not disabled.
> 
> So, I see two options:
> 
> 1. We did not disable port multicast context.
> 
> 2. We did disable the port multicast context, but the timer somehow got
> reactivated.
> 
> I will look into it...

FYI, I found the problem (and a reproducer). I will try to send a fix
later this week