Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 589614 - [rhel5.5] [kernel\network] unable to delete tun device - resource is busy
[rhel5.5] [kernel\network] unable to delete tun device - resource is busy
Status: CLOSED DUPLICATE of bug 672619
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: tunctl (Show other bugs)
5.5
All Other
low Severity high
: rc
: ---
Assigned To: Jiri Pirko
Red Hat Kernel QE team
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-06 10:53 EDT by Haim
Modified: 2015-05-04 21:19 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-21 05:21:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Haim 2010-05-06 10:53:27 EDT
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.
(END) 

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 10:55:17 EDT
The above bug kind of blocks our scenario as we fail to create and manage vms (VDSM).
Comment 2 Jiri Pirko 2010-05-12 06:59:43 EDT
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 08:01:45 EDT
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-27 22:42:42 EST
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-27 22:44:55 EST
Could someone please reassign this to whatever component that contains tunctl? Thanks!
Comment 6 RHEL Product and Program Management 2011-05-31 09:27:53 EDT
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 05:21:06 EST
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.