Re: ifconfig(8) on trying to destroy tap(4) interface used by a process

  Kyle Evans wrote:

> > 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.

Thanks for clarification.

Both changes look nice to have in stable/14, especially [1], which
should make device management/cleanup code a little simpler.

> > 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
>