From: James Bottomley <James.Bottomley@steeleye.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Mike Anderson <andmike@us.ibm.com>, Andrew Morton <akpm@osdl.org>,
greg@kroah.com, Jens Axboe <axboe@suse.de>,
linux-usb-devel@lists.sourceforge.net,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: bug 2400
Date: 04 Apr 2004 13:04:31 -0400 [thread overview]
Message-ID: <1081098273.2112.18.camel@mulgrave> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0404041216040.14668-100000@netrider.rowland.org>
On Sun, 2004-04-04 at 12:46, Alan Stern wrote:
> Ah, you have left out the third, bad alternative: open succeeds, user gets
> an fd that points to a deallocated device. More details below...
No, that would be a bug. I'm looking for evidence that such a bug exists
in sd.
> Let's consider a simple example, one that doesn't have all the
> complexities of the sr driver with its multiple driver layers. The
> usb-skeleton program in drivers/usb makes a good illustration; I added a
> semaphore to it some time ago to protect against exactly this sort of
> race. Without that semaphore, here's what can happen:
>
> Open process: Disconnect process:
>
> Get minor number from inode
> Lookup USB interface using
> minor number
> Get device pointer from the
> interface's private data
> and check it's not NULL
This is what's wrong. Here you should get a reference to the device
pointer (that's what scsi_device_get() actually does for us). If the
ref getting routine comes back with an error, you may not proceed. If
it comes back with a device, you own a reference to it and may go on
(even if the device is now gone, the structure will behave correctly).
> Get device pointer from the
> interface's private data
> Set the private data to NULL
> Lock the device sem
> Unregister the minor number
> Terminate ongoing I/O operations
> Clear the device->present flag
> Unlock the device
> Since the open count is 0,
> deallocate the device structure
You're not obeying the object lifetime rules here. The device may be
gone but the device structure must stay around (obviously in a special
state) until the last reference is dropped. Only after that may you
start nulling things out and killing it.
> Lock the device sem --> oops
This is because you're not using refcounted objects correctly.
If anyone can find a similar bug in the SCSI ULD's, I'll fix it, that's
why I asked for an example in sd (or sr with the current fixes) way back
in this thread.
James
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
next prev parent reply other threads:[~2004-04-04 17:04 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-01 21:15 bug 2400 Andrew Morton
2004-04-01 21:52 ` Matt Gulick
2004-04-01 22:08 ` Andrew Morton
2004-04-01 22:48 ` Matt Gulick
2004-04-01 22:40 ` James Bottomley
2004-04-01 22:53 ` Matt Gulick
2004-04-01 23:07 ` Matthew Dharm
2004-04-01 23:32 ` James Bottomley
2004-04-02 0:29 ` Steven Dake
2004-04-02 8:43 ` Mike Anderson
2004-04-02 15:57 ` James Bottomley
2004-04-02 16:45 ` Mike Anderson
2004-04-02 17:05 ` James Bottomley
2004-04-02 17:44 ` Mike Anderson
2004-04-02 18:13 ` James Bottomley
2004-04-02 23:40 ` Mike Anderson
2004-04-03 0:25 ` James Bottomley
2004-04-04 1:40 ` Alan Stern
2004-04-04 15:23 ` James Bottomley
2004-04-04 16:46 ` Alan Stern
2004-04-04 17:04 ` James Bottomley [this message]
2004-04-05 3:17 ` Alan Stern
2004-04-05 14:59 ` Mike Anderson
2004-04-05 21:27 ` James Bottomley
2004-04-06 14:00 ` Alan Stern
2004-04-05 22:10 ` Patrick Mansfield
2004-04-06 14:10 ` Alan Stern
2004-04-08 14:09 ` Alan Stern
2004-04-08 16:24 ` Matt Gulick
2004-04-08 18:33 ` Alan Stern
2004-04-08 19:44 ` Matt Gulick
2004-04-05 13:30 ` [linux-usb-devel] " Oliver Neukum
2004-04-04 18:16 ` David Brownell
2004-04-04 18:42 ` James Bottomley
2004-04-05 3:54 ` David Brownell
2004-04-05 21:44 ` James Bottomley
2004-04-05 23:23 ` [linux-usb-devel] " David Brownell
2004-04-06 1:19 ` James Bottomley
2004-04-06 6:52 ` Oliver Neukum
2004-04-06 14:03 ` James Bottomley
2004-04-07 9:19 ` Oliver.Neukum
2004-04-06 15:10 ` David Brownell
2004-04-06 15:47 ` James Bottomley
2004-04-06 16:16 ` David Brownell
2004-04-06 16:55 ` Alan Stern
2004-04-06 17:13 ` James Bottomley
2004-04-02 23:36 ` James Bottomley
2004-04-03 0:11 ` Mike Anderson
2004-04-03 0:16 ` James Bottomley
2004-04-05 4:33 ` Patrick Mansfield
2004-04-05 14:09 ` James Bottomley
2004-04-05 21:07 ` James Bottomley
2004-04-06 9:22 ` Jens Axboe
2004-04-06 13:56 ` James Bottomley
2004-04-06 14:04 ` Jens Axboe
2004-04-06 14:09 ` James Bottomley
2004-04-08 23:06 ` Greg KH
2004-04-09 11:28 ` James Bottomley
2004-04-05 14:03 ` Jens Axboe
2004-04-05 21:08 ` James Bottomley
2004-04-06 9:22 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2004-04-06 15:09 Heiko Carstens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1081098273.2112.18.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=andmike@us.ibm.com \
--cc=axboe@suse.de \
--cc=greg@kroah.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.