This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 57142 - umount of iso9660 file mounted with "mount -o loop" causes "ioctl: LOOP_CLR_FD: Device or resource busy" error
umount of iso9660 file mounted with "mount -o loop" causes "ioctl: LOOP_CLR_F...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: mount (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-05 13:35 EST by Roger Gaudet
Modified: 2007-04-18 12:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-02 02:22:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Roger Gaudet 2001-12-05 13:35:19 EST
Description of Problem:
Mounting an iso9660 image built with mkisofs on a loop device and then 
unmounting it causes the loop device to not be freed up. The error 
"ioctl: LOOP_CLR_FD: Device or resource busy" appears but the file is 
actually umounted (a subsequent 'umount' says the mount point is not 
mounted).  And "losetup -d" won't free the loop device.

Version-Release number of selected component (if applicable):
mount 2.11g

How Reproducible:
Every time.

Steps to Reproduce:
1. foo.img is an iso9660 image built with mkisofs (about 350MB)
2. assume no loop devices are in use
3. mount -t iso9660 -o loop foo.img /mnt/loop
4. ls /mnt/loop
   ...correct listing of foo.img appears...
5. umount /mnt/loop
ioctl: LOOP_CLR_FD: Device or resource busy
6. umount /mnt/loop
umount: /mnt/loop: not mounted
7: losetup /dev/loop0
/dev/loop6: [0302]:50785 (foo.img) offset 0, no encryption
8: losetup -d /dev/loop0
ioctl: LOOP_CLR_FD: Device or resource busy

Actual Results:
/dev/loop0 is "stuck" and can't be freed.  Eventually, repeating the 
above steps causes all loop devices to be "in use" and the only way to 
free them is to reboot.

Expected Results:
No "device or resource busy" error and the loop device should be free to 
be used again.

Additional Information:
"ps ax | grep loop" shows [loop0] still associated with the terminal 
device (in my case, pty/1).

The system is running all the latest released 7.2 updates (including 
kernel 2.4.9-13).

Upgrading losetup, mount and e2fsprogs to the versions from Rawhide 
didn't help.  Rawhide's mkisofs appears to be at the same version as that 
released with 7.2.

The problem does not occur when mounting and unmounting non-iso9660 
files.  For example:

dd if=/dev/zero of=file.img bs=1k count=1000
mke2fs -vm0 -q -F file.img
mount -o loop file.img /mnt/loop
<copy some stuff into /mnt/loop>
umount /mnt/loop

I can "mount -o loop file.img /mnt/loop" and then "umount /mnt/loop" as 
often as I like with no dangling loop devices.
Comment 1 Bernhard Rosenkraenzer 2001-12-13 12:07:05 EST
This looks like a kernel problem (one I can't reproduce, even).

Which kernel are you using?
Comment 2 Roger Gaudet 2001-12-13 13:51:04 EST
As stated in the "Additional Informaton" section, I'm running kernel 2.4.9-13. 
We've also seen this problem on a notebook running 2.4.7-10 (installed fresh
from the 7.2 CDs).

Are you sure you did your test with an iso9660 image?  We don't see the problem
with non-iso9660 images.
Comment 3 Roger Gaudet 2001-12-13 16:04:26 EST
As stated in the "Additional Informaton" section, I'm running kernel 2.4.9-13. 
We've also seen this problem on a notebook running 2.4.7-10 (installed fresh
from the 7.2 CDs).

Are you sure you did your test with an iso9660 image?  We don't see the problem
with non-iso9660 images.
Comment 4 Roger Gaudet 2001-12-13 16:08:54 EST
Sorry for the multiple posting.  For reasons still unclear my browser popped up
with a screen stating "someone else was changing this note at the same as you
were...do you want to save your changes" to which I said "yes."  Of course, that
"someone" was me.  Rookie mistake.  Doh!
Comment 5 Hans Deragon 2001-12-14 10:35:22 EST
I got the exact same problem, with the same kernel (2.4.9-13).  I got nothing
else to add.  Same receipe to reproduce, same error.

My current workaround is to load other images on under other loop devices
(loop1, loop2, etc...).  When I run out of loop devices, its reboot time.
Comment 6 Hans Deragon 2003-06-01 18:44:26 EDT
This problem does not exist anymore under RH 9.0.  Maybe its time to just close it?

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