Re: [PATCH 6.12 0000/1102] 6.12.111-rc1 review

[Barry K. Nathan]

On 9/19/26 10:07 AM, Sasha Levin wrote:
> On Sat, Sep 19, 2026 at 03:54:25AM -0700, Barry K. Nathan wrote:
> > > [   98.363843] RTNL: assertion failed at net/ipv6/mcast.c (1014)
> > > [   98.363896] WARNING: CPU: 6 PID: 961 at net/ipv6/mcast.c:1014 __ipv6_dev_mc_dec+0x17b/0x190 [ipv6]
>
> > I bisected it to this patch:
> > ipv6-mcast-don-t-hold-rtnl-for-ipv6_drop_membership-.patch.
>
> Your bisect is right, and thanks for chasing it all the way down --
> the splat is real and the patch you landed on is the trigger.
>
> I've dropped the ipv6 mcast RTNL conversion patches from the 6.12, 6.6
> and 5.15 queues.
>
> > If I take 6.12.110, apply the current stable-queue (as of commit
> > 01b20bb84b994fdcda64fd07a66ba84c85d0168f), then revert the
> > following patches:
> >
> > ipv6-mcast-don-t-hold-rtnl-for-ipv6_drop_membership-.patch
> > ipv6-mcast-don-t-hold-rtnl-for-mcast_-socket-options.patch
> > ipv6-mcast-use-copy-on-write-rcu-updates-in-ip6_mc_s.patch
> >
> > then the resulting kernel no longer shows these warnings at all.
>
> The root cause is a prerequisite we never picked up, rather than anything wrong
> with the patches themselves. Upstream commit e01b193e0b50a ("ipv6: mcast: Use
> in6_dev_get() in ipv6_dev_mc_dec().") is the commit in that series which
> deletes the now-stale ASSERT_RTNL() from __ipv6_dev_mc_dec(), and it was never
> backported to 6.12.y, 6.6.y or 5.15.y. So we took the patches that stop holding
> RTNL across the setsockopt paths while the assertion they were meant to retire
> was still sitting there -- hence net/ipv6/mcast.c:1014 firing on every
> IPV6_DROP_MEMBERSHIP. The queued patches are byte-identical cherry-picks of the
> upstream commits; this is a series-ordering gap on our side, not a botched
> backport.
>
> 7.2 and 6.18 carry the whole series, including e01b193e0b50a, so they
> are not affected and keep their copies.
>
> One difference from your experiment: I removed four patches rather than the
> three you reverted. The extra one is 1767bb2d47b7 ("ipv6: mcast: Don't hold
> RTNL for IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP."), which is a pure refactor
> of the join path and was only ever queued as a dependency of the others. It is
> harmless on its own so consistent with you not needing to revert it, but with
> the rest gone there is no reason to keep it, and dropping it keeps the series
> intact for a clean requeue.
>
> The plan is to requeue the complete ordered set, e01b193e0b50a included,
> once this RC is out.

Thanks for taking care of this!

I have now retested with 6.12.110 + stable-queue as of commit
afa3d2e7536e9034a4917d4b6e228a99d5bd7aa6 on my ThinkPad T14 Gen 1. I can
no longer reproduce this kernel warning (as expected with the patches
being dropped for now), and it's working well, and I have not observed
any other regressions.

Tested-by: Barry K. Nathan <barryn@xxxxxxxxx>

--
-Barry K. Nathan  <barryn@xxxxxxxxx>