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

[Sasha Levin <sashal@kernel.org>]

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,
Sasha