Bug 589614 - [rhel5.5] [kernel\network] unable to delete tun device - resource is busy
Summary: [rhel5.5] [kernel\network] unable to delete tun device - resource is busy
Status: CLOSED DUPLICATE of bug 672619
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: tunctl
Version: 5.5
Hardware: All
OS: Other
Target Milestone: rc
: ---
Assignee: Jiri Pirko
QA Contact: Red Hat Kernel QE team
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-06 14:53 UTC by Haim
Modified: 2015-05-05 01:19 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-11-21 10:21:06 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Haim 2010-05-06 14:53:27 UTC
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[4061]: Interface virtio_10_1.IPv6 no longer relevant for mDNS.
May  6 17:52:50 silver-vdsc avahi-daemon[4061]: 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[4061]: 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.

Comment 1 Haim 2010-05-06 14:55:17 UTC
The above bug kind of blocks our scenario as we fail to create and manage vms (VDSM).

Comment 2 Jiri Pirko 2010-05-12 10:59:43 UTC
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.

Comment 3 Dan Kenigsberg 2010-05-12 12:01:45 UTC
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.

Comment 4 Herbert Xu 2010-11-28 03:42:42 UTC
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.

Comment 5 Herbert Xu 2010-11-28 03:44:55 UTC
Could someone please reassign this to whatever component that contains tunctl? Thanks!

Comment 6 RHEL Program Management 2011-05-31 13:27:53 UTC
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.

Comment 7 Jiri Pirko 2012-11-21 10:21:06 UTC
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:
commit f986bd670f4307db7ad239bc645d92085e091809
Author: Michael S. Tsirkin <mst@redhat.com>
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 ***

Note You need to log in before you can comment on or make changes to this bug.