Date: Sat, 4 Oct 2025 08:41:28 -0500 From: Kyle Evans <kevans@FreeBSD.org> To: freebsd-net@freebsd.org Subject: Re: ifconfig(8) on trying to destroy tap(4) interface used by a process Message-ID: <87a30461-e2ee-4251-bad7-5bb900e85164@FreeBSD.org> In-Reply-To: <aOEZXmEwJYEDar3u@tulp> References: <aOEZXmEwJYEDar3u@tulp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/4/25 07:55, Roman Bogorodskiy wrote:
> Hi,
>
> Accidentally noticed ifconfig(8) and tap(4) behavior that seems strange
> to me: when I have a process using tap(4) and call ifconfig(8) destroy
> on this interface, ifconfig hangs.
>
> For example, in Python I do:
>
>>>> open('/dev/tap')
> <_io.TextIOWrapper name='/dev/tap' mode='r' encoding='UTF-8'>
>>>>
>
> And then:
>
> tap1: flags=1008842<BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
> options=4080000<LINKSTATE,MEXTPG>
> ether 58:9c:fc:10:5b:26
> groups: tap
> media: Ethernet 1000baseT <full-duplex>
> status: active
> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> Opened by PID 5409
> (14:45) novel@tulp:~ %> sudo ifconfig tap1 destroy
> load: 0.08 cmd: ifconfig 5620 [tun_condvar] 50.80r 0.00u 0.00s 0% 3576k
> mi_switch+0x172 sleepq_switch+0x109 sleepq_catch_signals+0x276 sleepq_wait_sig+0x9 _cv_wait_sig+0x165 tun_destroy+0x96 if_clone_destroyif_flags+0x69 if_clone_destroy+0x100 ifioctl+0xa0a kern_ioctl+0x286 sys_ioctl+0x12f amd64_syscall+0x169 fast_syscall_common+0xf8
>
> ifconfig keeps hanging like that and exits only when the process that
> owns the tap(4) interface releases it.
>
> I don't seem to find anything about that in manual pages for both
> tap(4) and ifconfig(8) (probably missed something), but generally, I'd
> expect ifconfig to immediately exit with an error and non-zero exit
> code.
>
I agree that it should be documented, but historically tun/tap have hung on
destroy if the cdev was still opened by a process. I made it interruptible[0]
somewhat recently, and also added a mode where tun/tap can be configured as
transient[1] so that they just naturally get destroyed on last close. Neither
of those have made it back to stable/14, but I don't think there's a reason
off-hand that they couldn't go back.
> Additionally, while trying to reproduce and document that, I've got a
> panic:
>
> FreeBSD tulp 16.0-CURRENT FreeBSD 16.0-CURRENT #6 main-n280778-f45608124286: Tue Sep 30 22:25:58 CEST 2025 root@tulp:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
>
> panic: deadlres_td_sleep_q: possible deadlock detected for 0xfffff80022425780 (ifconfig), blocked for 1802579 ticks
>
> I was able to reproduce this ifconfig(8) behavior on 14.3-RELEASE-p1
> too.
>
> Is it expected?
>
I think so, yeah.
> Thanks,
> Roman
>
[0] https://cgit.freebsd.org/src/commit/sys/net/if_tuntap.c?id=274bf7c8ae7e7b51853cd541481985f0e687f10e
[1] https://cgit.freebsd.org/src/commit/sys/net/if_tuntap.c?id=a1174b3b1174754b1f69406bff4456d002e8f583
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87a30461-e2ee-4251-bad7-5bb900e85164>