Bug 218310 - scsi midlayer race condition : scan vs block/unblock deadlocks sdev
scsi midlayer race condition : scan vs block/unblock deadlocks sdev
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Mike Christie
Brian Brock
:
Depends On:
Blocks: 217215
  Show dependency treegraph
 
Reported: 2006-12-04 11:20 EST by James Smart
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-03 22:35:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Smart 2006-12-04 11:20:45 EST
Description of problem:

We recently identified a bug in the upstream kernel, also present in SLES10.
Please include this patch in SLES10 SP1.

http://marc.theaimsgroup.com/?l=linux-scsi&m=116474894126200&w=2

Our testing has encountered an error between sdev initialization/
scanning and the sdev block/unblock behavior. What we have seen is that 
new target detection will kick off a scan, and that an sdev will be in 
the creation process with the state SDEV_CREATED. At this point a link 
event occurs, which blocks the sdev, changes its state to SDEV_BLOCK, 
and stops its request queue.  However, the creation thread is still 
executing, and decides to transition the sdev state to SDEV_RUNNING. 
Note that the request queue is still blocked. The sdev then gets unblocked, 
attempting to change the state to SDEV_RUNNING, which fails as it is already 
SDEV_RUNNING, which causes the unblock routine to bypass the call to 
blk_start_queue().

This patch modifies the creation path so that it only changes to SDEV_RUNNING
if the state is SDEV_CREATED. This allows the block/unblock to work 
appropriately. It does have a side effect that unblock could early-transition 
the sdev to SDEV_RUNNING.


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

RHEL5 Beta & RC kernels

How reproducible:

Cable Pull testing - pull immediately after first presentation to os.
Comment 4 Tom Coughlan 2006-12-12 13:56:41 EST
Do you expect this to be accepted upstream soon? 

Despite this:

> It does have a side effect that unblock could early-transition 
> the sdev to SDEV_RUNNING.

?

What is the impact? 
Comment 5 James Smart 2006-12-12 15:27:20 EST
Yes. As to when, you know how this works - it's under James B's control.
I'm pinging him to see why it hasn't been in rc-fixes yet.

Impact should be nothing. I haven't validated via code review, but I would
guess that :
a) there should be no i/o for the device as we're still in scsi_scan, so a
transition to RUNNING shouldn't matter;

b) I only believe we're at risk if something is validating the state while not
successfully completing scsi_scan. First, it is *very* rare we would not
complete scsi_scan successfully. Second, it makes little sense, in scsi_scan, to
validate sdev state.

c) My only risk is that scsi_scan can be a long process. Could be there may be
multiple scans outstanding, thus reuse/discovery of the sdev could be at risk.
However, I feel I'm being very hypothetical to even think of this.
Comment 6 Jay Turner 2006-12-13 21:38:35 EST
QE ack for RHEL5.
Comment 7 Tom Coughlan 2007-01-02 09:39:40 EST
Posted Fri, 22 Dec 2006
Comment 8 Tom Coughlan 2007-01-03 22:35:19 EST
Mike Christie pointed out some issues with this patch. It turns out that it is
not needed in RHEL 5. This request is withdrawn. 

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