From nobody Fri Dec 19 11:10:09 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dXlF53w4nz6LNvK; Fri, 19 Dec 2025 11:10:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dXlF5345Fz3QQj; Fri, 19 Dec 2025 11:10:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766142617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=biHezS3LDmnsWXb8fWCkT9QIeJIHSQiYBRZ6TsSOOZY=; b=LOf8N7q/zp/NGMUxMSz8kEEI0/E31BeNFziiYXQPxEarVK8SrXtO1RtCWHd5TDpCNweqo9 0TKpBEIp2Hl9OblmSQ4SpeXxicjBg8EKXg8v8OkG0Za3SYnJi2jSZ7M6x6obqGWy0lVumb EXqsaaa08fg9KPnL7IBetZRxdJL+1og+FbhUvgGEzHJiioxBjvQBrbBUFd7UyVau9fbDHx 4HXtuE451UalR2KhF+oAsHglV+B+9sEwCKmXe9Ligg1Pj2RSo+heErArTwG3nlUhMHa7Q9 4RA9i8hs1nj0iaen27D/kT0XDRvPiVzBLOxVMwbFiIVjLpyfJ2xVkDIQge8TxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766142617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=biHezS3LDmnsWXb8fWCkT9QIeJIHSQiYBRZ6TsSOOZY=; b=jdS6LzSzEt8AbFCtIETSsYnyRc5Wi3X5BZcxa3wRQujF47Ow46SW9K5S2DYE/LLHWA9jnx ufsllGu2I+wH1FF9v4cr1RXybroJV31FLQ7UqPRqD5XYgW/elwKhQuFrg6CCq6MZt5k2uT 1MZiYWu/k0oFjMmLkBt9xjssp0xnGE3Xj0cXxf66SPTNKwhU/isoTPfFCuv3KmN1w5DBc2 KwukEn2B8ImI8139AKKXp9M6aCHVxTUTn0ok1zrfy56Q+zYU3mVGdCwoEQoCz22wBd8tmc jyL5TSwAWw9u0jlpJ/sn70QYE9sJgxWaF3oXogydIPiONBOt/GqxtLUPmtq49g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766142617; a=rsa-sha256; cv=none; b=GYyLO647Dh5yZC0MZlUpneA6APhPPIxL6ZFiDUzo5qljRJMOwFCnvCV1YeuYYKtluXmyqA 4Hlq1jERW6uJ8BMniv+iC+idR+VkXd5XfKmykDt/nXDipQVqWp3JyqkZueso2jYmpT2Gxc tT1alaVcKN+XWwgR3FCuHL23sKIj8DpIs71VEp7NohKlBThMvwq0K7zmuWvGLeUAyLQgz7 DE0jsBLKdwalElK8UeM1E7dUiH91BSFcd7VYw3cs+u/N+Io4sG6KE8zMTochdh3154cKd9 +S3IqcwbFO4fuXyaHJcizENJivT3SzgVfhC5JxRnjglfnR3mdqhdAsL2BFAS8A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R12" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dXlF518dCzQvs; Fri, 19 Dec 2025 11:10:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 11379106B4; Fri, 19 Dec 2025 12:10:15 +0100 (CET) From: Kristof Provost To: Gleb Smirnoff Cc: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: 0d469d23715d - main - net: attach IPv4 and IPv6 stacks to an interface with EVENTHANDLER(9) Date: Fri, 19 Dec 2025 12:10:09 +0100 X-Mailer: MailMate (2.0r6272) Message-ID: <4A394DAA-1FCE-440A-8E92-88BD9B4EE087@FreeBSD.org> In-Reply-To: <694452f3.32deb.4d0ab2a7@gitrepo.freebsd.org> References: <694452f3.32deb.4d0ab2a7@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_EB1B9EEC-6095-4BD3-BD15-5B1CDB331F05_=" --=_MailMate_EB1B9EEC-6095-4BD3-BD15-5B1CDB331F05_= Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable 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=3D0d469d23715d690b863787ebfa515= 29e1f6a9092 > > commit 0d469d23715d690b863787ebfa51529e1f6a9092 > Author: Gleb Smirnoff > AuthorDate: 2025-12-18 16:47:39 +0000 > Commit: Gleb Smirnoff > 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=E2=80=99m seeing panics on pfsync interface destruction now: panic: mld_change_state: bad ifp cpuid =3D 19 time =3D 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 =3D 0x2d8234c9e31a, = rsp =3D 0x2d823179b928, rbp =3D 0x2d823179b9b0 --- KDB: enter: panic The pfsync:basic_ipv6 seems to trigger this reliably. Best regards, Kristof --=_MailMate_EB1B9EEC-6095-4BD3-BD15-5B1CDB331F05_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 18 Dec 2025, at 20:16, Gleb Smirnoff wrote:

The branch main has been updated by glebius:

URL: https://cgit.FreeBSD.org/src/co= mmit/?id=3D0d469d23715d690b863787ebfa51529e1f6a9092

commit 0d469d23715d690b863787ebfa51529e1f6a9092
Author: Gleb Smirnoff glebius@= FreeBSD.org
AuthorDate: 2025-12-18 16:47:39 +0000
Commit: Gleb Smirnoff glebius@= FreeBSD.org
CommitDate: 2025-12-18 19:15:53 +0000

ne=
t: 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.  Toda=
y
there is no good reason to treat IPv4 and IPv6 stacks differently to othe=
r
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 thi=
s
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 s=
tore, 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=E2=80=99m seeing panics on pfsync interface destruction= now:

pa=
nic: mld_change_state: bad ifp
cpuid =3D 19
time =3D 1766142554
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01843=
fd990
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 0xfffffe01843=
fdbf0
in6_leavegroup() at in6_leavegroup+0x32/frame 0xfffffe01843fdc10
pfsync_multicast_cleanup() at pfsync_multicast_cleanup+0x83/frame 0xfffff=
e01843fdc40
pfsync_clone_destroy() at pfsync_clone_destroy+0x260/frame 0xfffffe01843f=
dc90
ifc_simple_destroy_wrapper() at ifc_simple_destroy_wrapper+0x26/frame 0xf=
ffffe01843fdca0
if_clone_destroyif_flags() at if_clone_destroyif_flags+0x69/frame 0xfffff=
e01843fdce0
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 0xfffffe01843fdf3=
0
--- syscall (508, FreeBSD ELF64, jail_remove), rip =3D 0x2d8234c9e31a, rs=
p =3D 0x2d823179b928, rbp =3D 0x2d823179b9b0 ---
KDB: enter: panic

The pfsync:basic_ipv6 seems to trigger this reliably.

=

Best regards,
Kristof

--=_MailMate_EB1B9EEC-6095-4BD3-BD15-5B1CDB331F05_=--