* sd/usb deadlock
@ 2006-02-20 3:14 Tom Scanlan
0 siblings, 0 replies; only message in thread
From: Tom Scanlan @ 2006-02-20 3:14 UTC (permalink / raw)
To: linux-scsi
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
Not sure if I should report this or ask around elsewhere... This was
also sent to drew@colorado.edu, as he was first in sd.c.
sd_open in drivers/scsi/sd.c seems to have a deadlock. It was noticed
when plugging and unplugging lots of usb disks in random order on a slow
machine. The hotplug scripts were running fdisk -l on the devices and
trying to mount the disks as they were getting (un)plugged. I saw this
in version 2.4.21, but the code is the same at least up to 2.4.30.
revalidate_scsidisk marks the disk as busy, then we hit an sd_open and
got stuck in a loop waiting for the disk to become not busy. The change
is to fail on open if the disk is busy. Requiring a mount retry is
better behavior than hanging the kernel.
The diff is attached... I'm not sure the process to getting it in a
release... pointers would be helpful. If there is a reason this
shouldn't be used let me know, as I'm not much of a kernel hacker.
[-- Attachment #2: sd.c.diff --]
[-- Type: text/plain, Size: 451 bytes --]
--- sd.c 2006-02-10 12:22:41.000000000 -0500
+++ sd.c~ 2006-02-08 16:27:31.000000000 -0500
@@ -466,10 +466,15 @@
* is being re-read.
*/
- if (rscsi_disks[target].device->busy) {
- printk("device %d was busy, can't open it, try again soon.\n", target);
- return -ENXIO;
- }
+
+ while (rscsi_disks[target].device->busy) {
+ barrier();
+ cpu_relax();
+ }
+
/*
* The following code can sleep.
* Module unloading must be prevented
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2006-02-20 3:14 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-20 3:14 sd/usb deadlock Tom Scanlan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).