Bug 131136 - [Patch] Simultaneous calls to open() on a usb device hangs the kernel
Summary: [Patch] Simultaneous calls to open() on a usb device hangs the kernel
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Larry Woodman
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 156320
TreeView+ depends on / blocked
 
Reported: 2004-08-27 20:52 UTC by Don Howard
Modified: 2010-10-22 02:37 UTC (History)
7 users (show)

Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-28 14:28:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Fujitsu to correct hang on open() of usb device. (5.08 KB, patch)
2004-08-27 20:57 UTC, 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 22:44 UTC, Don Howard
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:663 0 qe-ready SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 6 2005-09-28 04:00:00 UTC

Description Don Howard 2004-08-27 20:52:53 UTC
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): 
kernel-2.4.9-e.43 
 
How reproducible: 
Always 
 
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 
setup. 
 
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 
Escalating.... 
 
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. 
 
Regards, 
Fuchi 
 
 
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. 
 
http://172.16.32.107/IT/44721/  
 
It seem that the busy-looped process is looping with kernel-lock. so 
onther CPU is wating kernel-lock and become hung. 
 
Thanks, 
Fuchi

Comment 1 Don Howard 2004-08-27 20:54:47 UTC
Also reported against pensacola in bug #131133 

Comment 2 Don Howard 2004-08-27 20:57:19 UTC
Created attachment 103187 [details]
Fujitsu to correct hang on open() of usb device.

Comment 4 Pete Zaitcev 2004-09-14 04:22:51 UTC
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 22:44:09 UTC
Created attachment 104464 [details]
updated patch from fujitsu that drop extra cruft not related to this bug.

Comment 10 Ernie Petrides 2005-06-17 00:13:02 UTC
Patch posted for review on 16-Jun-2005.

Comment 11 Ernie Petrides 2005-06-17 23:00:17 UTC
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 14:28:59 UTC
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.

http://rhn.redhat.com/errata/RHSA-2005-663.html



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