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
