Bug 131136 - [Patch] Simultaneous calls to open() on a usb device hangs the kernel
[Patch] Simultaneous calls to open() on a usb device hangs the kernel
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Larry Woodman
Brian Brock
Depends On:
Blocks: 156320
  Show dependency treegraph
Reported: 2004-08-27 16:52 EDT by Don Howard
Modified: 2010-10-21 22:37 EDT (History)
7 users (show)

See Also:
Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 10:28:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fujitsu to correct hang on open() of usb device. (5.08 KB, patch)
2004-08-27 16:57 EDT, Don Howard
no flags Details | Diff
updated patch from fujitsu that drop extra cruft not related to this bug. (1.72 KB, patch)
2004-09-28 18:44 EDT, Don Howard
no flags Details | Diff

  None (edit)
Description Don Howard 2004-08-27 16:52:53 EDT
The system will be hang, if open() is called for /dev/sdb at the 
same time. 
Action by: fuchi 
Description of problem: 
The system will be hang, if open() is called for /dev/sdb at the 
same time.  /dev/sdb is USB FDD (low-speed device), it is necessary 
conditions for /dev/sdb. 
Version-Release number of selected component (if applicable): 
How reproducible: 
Steps to Reproduce: 
Please get USB Floppy driver and FD 
1. Boot the system. 
2. Create the 3 filesytems on floppy disk as follows. 
   # parted /dev/sdb mkpartfs primary ext2 0 0.4686 
   # parted /dev/sdb mkpartfs primary ext2 0.4687 0.9372 
   # parted /dev/sdb mkpartfs primary ext2 0.9373 1.4060 
3. Exeucte the following command on the shell 
   #while : ; do fsck -t ext2 -p -y /dev/sdb1 & fsck -t ext2 -p -y 
/dev/sdb2 & fsck -t ext2 -p -y /dev/sdb3 ; done 
4. Unplug USB floppy drive. 
5. Then, we can see the system hang. 
6. We can take netdump log and crash dump, if netdump client was 
Actual results: 
The system hang. 
Expected results: 
no hang. 
Additional info: 
RHEL3 also has this problem. We can see this problem on RHEL3. 
Action by: fuchi 
This is 100% reproducible on the slow-speed device. 
We may be able to see this problem with USB ZIP drive or MO drive. 
And Fujitsu kernel dev team have created the patch for this prolbem. 
I checked that a problem was solved with this patch. so I'd like to 
review this patch. 
Issue escalated to Support Engineering Group by: fuchi 
.File uploaded: fj-linux-2.4.9-removable-strage-29625.patch 
Action by: fuchi 
Opening the device(only slow device) at the same time. 
So we can see this problem using fsck, mount and a lots of command. 
I also could reproduce this problem on RHEL3. So I have gotten the 
crash log(vmcore). we can analyze kenel crash data on RHEL3. 
Please download from the following site.  
It seem that the busy-looped process is looping with kernel-lock. so 
onther CPU is wating kernel-lock and become hung. 
Comment 1 Don Howard 2004-08-27 16:54:47 EDT
Also reported against pensacola in bug #131133 
Comment 2 Don Howard 2004-08-27 16:57:19 EDT
Created attachment 103187 [details]
Fujitsu to correct hang on open() of usb device.
Comment 4 Pete Zaitcev 2004-09-14 00:22:51 EDT
The strange wordage of the original report has to do with the
bug originally reported on AS 2.1, see bug 131133.
But yes, this is RHEL 3 bug.

I suspect Fujitsu is on to something here, minus a few
small items. The patch is somewhat rotten by the pointless
attempts to avoid "ABI change" (unused SDev).
The removal of the retarded busy-loop was good, but it caused a change
in behaviour: now simultaneous opens can bomb instead of waiting.

I can clean sd.c up, but I need Doug to look at what they did
to the device->busy.
Comment 8 Don Howard 2004-09-28 18:44:09 EDT
Created attachment 104464 [details]
updated patch from fujitsu that drop extra cruft not related to this bug.
Comment 10 Ernie Petrides 2005-06-16 20:13:02 EDT
Patch posted for review on 16-Jun-2005.
Comment 11 Ernie Petrides 2005-06-17 19:00:17 EDT
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-32.9.EL).
Comment 17 Red Hat Bugzilla 2005-09-28 10:28:59 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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