Description of problem:
The following issue happened during tests of rhev-m and vdsm (qemu-kvm):
Iwe try to delete tun device with 'tunctl -d virtio_10_1' and we get 'TUNSETIFF: Device or resource busy'.
The following appears in /var/log/messages
May 6 17:36:12 silver-vdsc kernel: device virtio_10_1 left promiscuous mode
May 6 17:36:12 silver-vdsc kernel: rhevm: port 2(virtio_10_1) entering disabled state
May 6 17:52:50 silver-vdsc avahi-daemon: Interface virtio_10_1.IPv6 no longer relevant for mDNS.
May 6 17:52:50 silver-vdsc avahi-daemon: Leaving mDNS multicast group on interface virtio_10_1.IPv6 with address fe80::fc1a:4aff:fe16:8414.
May 6 17:52:50 silver-vdsc avahi-daemon: Withdrawing address record for fe80::fc1a:4aff:fe16:8414 on virtio_10_1.
I am using kernel 2.6.18-194.el5.
I doubt if this issue will repro again. please provide me with information on how to debug or what information you might need.
The above bug kind of blocks our scenario as we fail to create and manage vms (VDSM).
hmm, from "rhevm: port 2(virtio_10_1) entering disabled state" that's obvious that virtio_10_1 is a port in a bridge named "rhevm". Therefore "tunctl -d" fails. If you want to remove the tun device, first release it from the bridge. Hope this clears it. Closing this as notabug, feel free to reopen.
99.9% of the times, `tunctl -d` has no problem operating on a tap device that happens to be connected to a bridge.
Yet in this particular case, it failed. The failure persisted even after we deleted virtio_10_1 from the bridge. Our only way to get rid of it was to reboot the machine. Even if our userland behavior is impolite, kernel must respond reasonably.
Why is tunctl doing a TUNSETIFF? That seems counterintuitive when you're trying to delete the device.
FWIW ip link should be able to delete the device successfully regardless of what state it's in, in fact this is how we discovered many of the races that tun.c had if you deleted a live device :)
So to summarise this is a user-space bug.
Could someone please reassign this to whatever component that contains tunctl? Thanks!
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Although Herbert suggested this is userspace issue, I disagree. This is kernel issue. It is ok to do TUNSETIFF on existing tun iface and doing this resulting in -EBUSY is bug in this situation. Looks like upstream commit a7385ba21102a90f902055f9f185ca02bf62fa43 is resolving this. This has been backported to rhel5 in commit:
Author: Michael S. Tsirkin <firstname.lastname@example.org>
Date: Wed Dec 22 21:11:52 2010 -0500
I believe this should be no longer an issue. Closing this as dup of 672619. Feel free to reopen this when you come across the issue again.
*** This bug has been marked as a duplicate of bug 672619 ***