Bug 242841
| Summary: | tun(4): Unkillable process when attempting to destroy an open tun device | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Colin Percival <cperciva> |
| Component: | kern | Assignee: | Kyle Evans <kevans> |
| Status: | Open --- | ||
| Severity: | Affects Many People | CC: | kevans, net |
| Priority: | --- | Keywords: | needs-qa |
| Version: | 12.1-RELEASE | Flags: | koobs:
mfc-stable12?
koobs: mfc-stable11? |
| Hardware: | Any | ||
| OS: | Any | ||
Taking as one of the last to touch tuntap. I don't see any reason not to do this. We do in general have a problem with applications not actually keeping the owner pid up to date, but it would at least catch the common case. |
This is admittedly partly a case of "don't do that" (I tripped over it due to a bug in code I was writing), but it seems like the kernel should handle it a bit more gracefully. If you: 1. Create a tun device (via SIOCIFCREATE), 2. Open the tun device (via open("/dev/tun#")), and then 3. Attempt to destroy the tun device (via SIOCIFDESTROY), the SIOCIFDESTROY ioctl will block on tun_condvar until the last file descriptor holding the device open has been closed. Generally sensible... except that the file descriptor in question is owned by the process which called the ioctl, and it's stuck inside the kernel now and will never be able to close the device. This results in a process which cannot be killed. A better solution might be to detect when the process calling SIOCIFDESTROY is the same as the process which owns the tunnel device, and return an error (maybe EBUSY) rather than blocking indefinitely.