* BUG in sd.c
@ 2004-02-04 16:13 Alan Stern
2004-02-04 17:14 ` Mike Anderson
0 siblings, 1 reply; 3+ messages in thread
From: Alan Stern @ 2004-02-04 16:13 UTC (permalink / raw)
To: SCSI development list; +Cc: Frank Pieczynski
The following Bugzilla entry:
http://bugme.osdl.org/show_bug.cgi?id=1986
reports a problem with a USB card reader. The cause and resolution of
that problem are irrelevant to this list, but the manifestation of the
problem may have been that the device replied with Check Condition (and no
sense data) to every command.
At any rate, this caused an oops as a result of sd.c calling
scsi_disk_get() after the device's reference count had gone to 0. Can
someone look at this and see if sd.c needs to be fixed?
Alan Stern
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: BUG in sd.c
2004-02-04 16:13 BUG in sd.c Alan Stern
@ 2004-02-04 17:14 ` Mike Anderson
2004-02-19 15:00 ` Alan Stern
0 siblings, 1 reply; 3+ messages in thread
From: Mike Anderson @ 2004-02-04 17:14 UTC (permalink / raw)
To: Alan Stern; +Cc: SCSI development list, Frank Pieczynski
Alan Stern [stern@rowland.harvard.edu] wrote:
> The following Bugzilla entry:
>
> http://bugme.osdl.org/show_bug.cgi?id=1986
>
> reports a problem with a USB card reader. The cause and resolution of
> that problem are irrelevant to this list, but the manifestation of the
> problem may have been that the device replied with Check Condition (and no
> sense data) to every command.
>
> At any rate, this caused an oops as a result of sd.c calling
> scsi_disk_get() after the device's reference count had gone to 0. Can
> someone look at this and see if sd.c needs to be fixed?
>
> Alan Stern
Just a quick look. We are racing scsi_disk_release with sd_open. The
return code check in scsi_disk_get from the call to kobject_get is
worthless. The kobject_get will take do a inc even if we may already be
in release. This will cause a oops as we will fail the scsi_device_get
call in scsi_disk_get which will cause a call to kobject_put on a struct
that will most likely be free'd.
Maybe I am still reading the block layer locking wrong, but I do not see a
method to close the race with blkdev_open. I will look at this some more
and see if I can get a clue what I am missing.
-andmike
--
Michael Anderson
andmike@us.ibm.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: BUG in sd.c
2004-02-04 17:14 ` Mike Anderson
@ 2004-02-19 15:00 ` Alan Stern
0 siblings, 0 replies; 3+ messages in thread
From: Alan Stern @ 2004-02-19 15:00 UTC (permalink / raw)
To: Mike Anderson; +Cc: SCSI development list
On Wed, 4 Feb 2004, Mike Anderson wrote:
> Just a quick look. We are racing scsi_disk_release with sd_open. The
> return code check in scsi_disk_get from the call to kobject_get is
> worthless. The kobject_get will take do a inc even if we may already be
> in release. This will cause a oops as we will fail the scsi_device_get
> call in scsi_disk_get which will cause a call to kobject_put on a struct
> that will most likely be free'd.
>
> Maybe I am still reading the block layer locking wrong, but I do not see a
> method to close the race with blkdev_open. I will look at this some more
> and see if I can get a clue what I am missing.
Did you ever find anything in the block layer to prevent the race between
open and release?
If there's nothing there, does this mean that protection needs to be added
to the sd and sr drivers? What about sg, which doesn't use the blocking
layer? This race is generic; every device driver needs to deal with it
somehow.
Alan Stern
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-02-19 15:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-04 16:13 BUG in sd.c Alan Stern
2004-02-04 17:14 ` Mike Anderson
2004-02-19 15:00 ` Alan Stern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox