[Bug 290575] sys/net/if_tun_test:transient test fails intermittently in CI

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 05 Nov 2025 00:28:28 UTC
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.