From: Mike Anderson <andmike@us.ibm.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: 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>,
stern@rowland.harvard.edu
Subject: Re: bug 2400
Date: Fri, 2 Apr 2004 09:44:42 -0800 [thread overview]
Message-ID: <20040402174442.GE3880@us.ibm.com> (raw)
In-Reply-To: <1080925518.1830.93.camel@mulgrave>
James Bottomley [James.Bottomley@SteelEye.com] wrote:
> On Fri, 2004-04-02 at 11:45, Mike Anderson wrote:
> > Maybe some clarification here as I am unsure if we both think there
> > needs to be a notification (a put call) from outside SCSI. We have
> > release functions available on most objects in SCSI now. The issue is
> > that when we register (add_disk, dev_set_drvdata, etc.) or pass a handle
> > to another subsystem we need a reference count agreement to know when
> > the other subsystem is done with the the object. Something like the
> > put_device(parent) used in scsi_host_dev_release.
>
> Actually, no, that's not the issue here, if I understand you. The
> reference counting model on the sdev->sdev_gendev seems to be working
> correctly because sr.c takes a reference to the sdev_gendev on open and
> drops it on close.
>
> The problem is that ULDs are implemented as struct device_drivers and as
> such, their ->remove method gets called *not* on last put of sdev_gendev
> but on device_del (when there are still active references).
The remove can do as much or as little as the implementor wishes, but I
believe there is still a under lying issue here (see comment below).
>
> sr.c frees the cdinfo structure on ->remove, but still has its own
> reference to sdev_gendev (because the device is still open). On final
> close, the generic cdrom code tries to use cdinfo to close the device
> and references a kfree'd structure. Really what sr.c wants to be doing
> is freeing the cdinfo structure on last put, not on device_del.
>
Where does the last put come from? How do you close the open race or
know when the final put_disk has been called? SCSI cannot do this alone
as we have created and registered an object in another subsystem
(alloc_disk and add_disk) and we have no indication when that objects
ref count has reached zero.
Or
As I previous stated in the thread below I have the gendisk /
block layer locking mis-understood and there is something that SCSI can
do.
For reference you can look at this thread sent by Alan about a sd race.
http://marc.theaimsgroup.com/?t=107591185800003&r=1&w=2
While freeing in sr could be rearranged more like what sd does there is
still the issue of a cross subsystem put to know that the ULDs open
function will not be called again.
-andmike
--
Michael Anderson
andmike@us.ibm.com
next prev parent reply other threads:[~2004-04-02 17:44 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 [this message]
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
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=20040402174442.GE3880@us.ibm.com \
--to=andmike@us.ibm.com \
--cc=James.Bottomley@SteelEye.com \
--cc=akpm@osdl.org \
--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.