On 18 Dec 2025, at 20:16, Gleb Smirnoff wrote:
The branch main has been updated by glebius:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0d469d23715d690b863787ebfa51529e1f6a9092
commit 0d469d23715d690b863787ebfa51529e1f6a9092
Author: Gleb Smirnoff <[email protected]>
AuthorDate: 2025-12-18 16:47:39 +0000
Commit: Gleb Smirnoff <[email protected]>
CommitDate: 2025-12-18 19:15:53 +0000
net: attach IPv4 and IPv6 stacks to an interface with
EVENTHANDLER(9)
This change retires two historic relics: the if_afdata[] array and
the
dom_ifattach/dom_ifdetach methods.
The if_afdata[] array is a relic of the era, when there was
expectation
that many transport protocols will coexist with IP, e.g. IPX or
NetAtalk.
The array hasn't had any members except AF_INET and AF_INET6 for
over a
decade already. This change removes the array and just leaves two
pointer
fields: if_inet and if_inet6.
The dom_ifattach/dom_ifdetach predates the EVENTHANDLER(9)
framework and
was a good enough method to initialize protocol contexts back
then. Today
there is no good reason to treat IPv4 and IPv6 stacks differently
to other
protocols/features that attach and detach from an interface.
The locking of if_afdata[] is a relic of SMPng times, when the
system
startup and the interface attach was even more convoluted than
before this
change, and we also had unloadable protocols that used a field in
if_afdata[]. Note that IPv4 and IPv6 are not unloadable.
Note that this change removes NET_EPOCH_WAIT() from the interface
detach
sequence. This may surface several new races associated with
interface
removal. I failed to hit any with consecutive test suite runs,
though.
The expected general race scenario is that while struct ifnet is
freed
with proper epoch_call(9) itself, some structures hanging off
ifnet are
freed with direct free(9). The proper fix is either make if_foo
point at
some static "dead" structure providing SMP visibility of this
store, or
free those structure with epoch_call(9). All of these cases are
planned
to be found and resolved during 16.0-CURRENT lifetime.
Reviewed by: zlei, gallatin, melifaro
Differential Revision: https://reviews.freebsd.org/D54089
I’m seeing panics on pfsync interface destruction now:
panic: mld_change_state: bad ifp
cpuid = 19
time = 1766142554
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfffffe01843fd990
vpanic() at vpanic+0x136/frame 0xfffffe01843fdac0
panic() at panic+0x43/frame 0xfffffe01843fdb20
mld_change_state() at mld_change_state+0x6d0/frame 0xfffffe01843fdb90
in6_leavegroup_locked() at in6_leavegroup_locked+0xa9/frame
0xfffffe01843fdbf0
in6_leavegroup() at in6_leavegroup+0x32/frame 0xfffffe01843fdc10
pfsync_multicast_cleanup() at pfsync_multicast_cleanup+0x83/frame
0xfffffe01843fdc40
pfsync_clone_destroy() at pfsync_clone_destroy+0x260/frame
0xfffffe01843fdc90
ifc_simple_destroy_wrapper() at ifc_simple_destroy_wrapper+0x26/frame
0xfffffe01843fdca0
if_clone_destroyif_flags() at if_clone_destroyif_flags+0x69/frame
0xfffffe01843fdce0
if_clone_detach() at if_clone_detach+0xe6/frame 0xfffffe01843fdd10
vnet_pfsync_uninit() at vnet_pfsync_uninit+0xf0/frame
0xfffffe01843fdd30
vnet_destroy() at vnet_destroy+0x154/frame 0xfffffe01843fdd60
prison_deref() at prison_deref+0xaf5/frame 0xfffffe01843fddd0
sys_jail_remove() at sys_jail_remove+0x15c/frame 0xfffffe01843fde00
amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe01843fdf30
fast_syscall_common() at fast_syscall_common+0xf8/frame
0xfffffe01843fdf30
--- syscall (508, FreeBSD ELF64, jail_remove), rip = 0x2d8234c9e31a,
rsp = 0x2d823179b928, rbp = 0x2d823179b9b0 ---
KDB: enter: panic
The pfsync:basic_ipv6 seems to trigger this reliably.
Best regards,
Kristof
