Date: Wed, 05 Nov 2025 00:28:28 +0000 From: bugzilla-noreply@freebsd.org To: testing@FreeBSD.org Subject: [Bug 290575] sys/net/if_tun_test:transient test fails intermittently in CI Message-ID: <bug-290575-32464-mQYvD4gTqA@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-290575-32464@https.bugs.freebsd.org/bugzilla/> References: <bug-290575-32464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290575 --- Comment #5 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=96c1d8db39dfeea78ea3f27d67649252a39bbf2e commit 96c1d8db39dfeea78ea3f27d67649252a39bbf2e Author: Kyle Evans <kevans@FreeBSD.org> AuthorDate: 2025-11-05 00:28:02 +0000 Commit: Kyle Evans <kevans@FreeBSD.org> CommitDate: 2025-11-05 00:28:02 +0000 if_tuntap: defer transient destroy_dev() to a taskqueue We're in the dtor, so we can't destroy it now without deadlocking after recent changes to make destroy_dev() provide a barrier. However, we know there isn't any other dtor to run, so we can go ahead and clean up our state and just prevent a use-after-free if someone races to open the device while we're trying to destroy it. tunopen() now uses the net epoch to protect against softc release by a concurrent tun_destroy(). While we're here, allow a destroy operation to proceed if we caught a signal in cv_wait_sig() but tun_busy dropped to 0 while we were waiting to acquire the lock. This was more of an inherent design flaw, rather than a bug in the below-refed commit. PR: 290575 Fixes: 4dbe6628179d ("devfs: make destroy_dev() a release [...]") Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D53438 sys/net/if_tuntap.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 57 insertions(+), 6 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-290575-32464-mQYvD4gTqA>