Bug 116037 - Existence of race condition in Linux SD driver that leads to a deadlock
Existence of race condition in Linux SD driver that leads to a deadlock
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Larry Woodman
Brian Brock
Depends On:
Blocks: 156320
  Show dependency treegraph
Reported: 2004-02-17 14:24 EST by Heather Conway
Modified: 2007-11-30 17:07 EST (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:19:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch committed to rhel3 u6 (269 bytes, patch)
2005-09-12 16:47 EDT, Ernie Petrides
no flags Details | Diff

  None (edit)
Description Heather Conway 2004-02-17 14:24:34 EST
Description of problem:
Linux sd driver has a race condition, which will lead to a deadlock. 
It is there on all linux versions that we support, but only shows up 
on RHEL 3.0 with PowerPath, since RedHat inroduced a package called 
devlabel with it. The race happens under the following conditions.

Thread #1 can call scsi_revalidatedisk(), while holding the 
kernel_flag (i.e. the big lock), and may do IO. This function will 
set the device_busy flag for the particular device. Thread#2 will 
come along, and attempt to open the device that is being revalidated. 
It will obtain the lock, since thread #1 releases before the call to 
schedule (). Thread #2 will then spin in the following while loop in 
sd_open() causing a deadlock, since thread#1 never reset the busy 
flag, and will never get a chance to do so.

while (rscsi_disks[target].device->busy) {

This is a bug in LINUX. Somebody at Egenera also ran into this issue. 
Here's the link:


Version-Release number of selected component (if applicable):
Comment 1 Rik van Riel 2004-02-17 14:39:27 EST
Can you reproduce this problem without the proprietary powerpath module?

If not, I'm afraid there isn't much we can do without your help,
because the powerpath source code isn't available to us (under an
acceptable license).
Comment 2 Heather Conway 2004-02-21 13:57:10 EST
I will request that the environment be replicated without PowerPath 
and will update the bugzilla as soon as I have an answer back.  
Comment 3 Gary Mansell 2004-08-31 10:13:14 EDT
Is there still a problem with this on RHAS 3.0 v2.4.21 9.0.1.EL and
Powerpath 3.0.5?
Comment 4 Ernie Petrides 2005-06-16 20:10:09 EDT
Patch posted for review on 16-Jun-2005.
Comment 5 Ernie Petrides 2005-06-17 18:57:26 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 10 Ernie Petrides 2005-09-12 16:47:01 EDT
Created attachment 118740 [details]
patch committed to rhel3 u6
Comment 12 Red Hat Bugzilla 2005-09-28 10:19:06 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.