From: Oliver Neukum <oliver@neukum.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg KH <gregkh@suse.de>,
stable@kernel.org, Rickard Bellini <rickard.bellini@ericsson.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Torgny Johansson <torgny.johansson@ericsson.com>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Driver core: fix race in dev_driver_string
Date: Fri, 4 Dec 2009 22:58:48 +0100 [thread overview]
Message-ID: <200912042258.48323.oliver@neukum.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0912041625360.3070-100000@iolanthe.rowland.org>
Am Freitag, 4. Dezember 2009 22:36:22 schrieb Alan Stern:
> > > Typically the driver would take a reference during open() and drop it
> > > during close().
> >
> >
> > You can do that but then you must not do IO prior to open() or after
> > close(). That is you must actually wait for IO to finish in close() and
> > cannot prefill your buffers before open().
>
> If open() or close() is called before disconnect() then you don't have
> to worry.
>
> If close() is called after disconnect() there's nothing to wait for,
> because disconnect() should call usb_kill_urb() on all outstanding
> transfers (actually usbcore will do that for you). Likewise with
> open().
>
> The problem in this example stems from the fact that you are using
> instance->dev at a time when you don't know that it is valid -- in
> fact, you have good reason to believe it _isn't_ valid because
> instance->disconnected is set.
OK, yes. It's a bad example. However this is tricky.
This is a bug then:
mutex_lock(...);
if (instance->error) {
rv = instance->error;
instance->error = 0;
dev_dbg(instance->dev,...);
goto err_out;
}
rv = -ENODEV;
if (instance->disconnected)
goto err_out;
> One approach is to set instance->dev to NULL in disconnect(). That
> wouldn't do much good for your dev_dbg(), though. A better solution is
> to refcount the instance->dev pointer: Take a reference to the device
> when setting instance->dev and drop it when clearing instance->dev (or
> when instance is freed).
That would mean that I am forced to adopt refcounting just to print
something. This seems very inelegant.
Regards
Oliver
next prev parent reply other threads:[~2009-12-04 21:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20091204044337.GE14819@suse.de>
2009-12-04 16:06 ` Alan Stern
2009-12-04 16:16 ` Oliver Neukum
2009-12-04 16:50 ` Greg KH
2009-12-04 19:55 ` Oliver Neukum
2009-12-04 20:57 ` Alan Stern
2009-12-04 21:18 ` Oliver Neukum
2009-12-04 21:36 ` Alan Stern
2009-12-04 21:58 ` Oliver Neukum [this message]
2009-12-04 22:07 ` Alan Stern
2009-12-04 22:23 ` Dmitry Torokhov
2009-12-04 23:50 ` Alan Stern
2009-12-05 0:35 ` Greg KH
2009-12-05 2:37 ` Alan Stern
2009-12-05 0:33 ` Greg KH
2009-12-04 16:57 ` Alan Stern
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=200912042258.48323.oliver@neukum.org \
--to=oliver@neukum.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rickard.bellini@ericsson.com \
--cc=stable@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=torgny.johansson@ericsson.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®