Re: git: 0d469d23715d - main - net: attach IPv4 and IPv6 stacks to an interface with EVENTHANDLER(9)

In reply to: Gleb Smirnoff : "Re: git: 0d469d23715d - main - net: attach IPv4 and IPv6 stacks to an interface with EVENTHANDLER(9)"
Go to: [ bottom of page ] [ top of archives ] [ this month ]

From: Mateusz Guzik <mjguzik_at_gmail.com>
Date: Tue, 13 Jan 2026 19:26:31 UTC

On Tue, Jan 13, 2026 at 8:12 PM Gleb Smirnoff <glebius@freebsd.org> wrote:
>
> On Mon, Jan 12, 2026 at 05:15:30PM +0100, Mateusz Guzik wrote:
> M> In addition to the other reports there is also the following:
> M> panic: mtx_lock() of spin mutex (null) @
> M> /var/jenkins/workspace/pfSense-Plus-snapshots-master-main/sources/FreeBSD-src-plus-devel-main/sys/netinet/igmp.c:627
> M> cpuid = 1
> M> time = 1
> M> KDB: enter: panic
> M> [ thread pid 0 tid 100000 ]
> M> Stopped at      kdb_enter+0x33: movq    $0,0x1b23e72(%rip)
> M> db> bt
> M> Tracing pid 0 tid 100000 td 0xffffffff828665e0
> M> kdb_enter() at kdb_enter+0x33/frame 0xffffffff83963cb0
> M> panic() at panic+0x43/frame 0xffffffff83963d10
> M> __mtx_lock_flags() at __mtx_lock_flags+0x12f/frame 0xffffffff83963d60
> M> igmp_domifattach() at igmp_domifattach+0x24/frame 0xffffffff83963d80
> M> in_ifattach() at in_ifattach+0xb2/frame 0xffffffff83963db0
> M> if_attach_internal() at if_attach_internal+0x374/frame 0xffffffff83963e00
> M> enc_clone_create() at enc_clone_create+0x7e/frame 0xffffffff83963e30
> M> if_clone_createif_nl() at if_clone_createif_nl+0x166/frame 0xffffffff83963ea0
> M> ifc_create_ifp() at ifc_create_ifp+0x102/frame 0xffffffff83963f10
> M> vnet_enc_init() at vnet_enc_init+0x97/frame 0xffffffff83963f70
> M> vnet_register_sysinit() at vnet_register_sysinit+0x125/frame 0xffffffff83963fa0
> M> mi_startup() at mi_startup+0x1f4/frame 0xffffffff83963ff0
> M> db>
>
> I'm pretty sure this is fixed by this commit:
>
> https://github.com/freebsd/freebsd-src/commit/99e133e0de272396e351b06ba892ceec7d5e0e4b
>
> which I created in a different branch, related to a similar regression with
> IPv6 multicast.  The enc was mangling MLD list from the very beginning but that
> was not panicing, since MLD had a workaround to not double delete already
> deleted entries.
>
> If you confirm that this commit fixes your problem, I will push it without
> waiting for the resolution of that branch as a whole.
>

i confirm it fixes the issue

> --
> Gleb Smirnoff