From: Alan Stern <stern@rowland.harvard.edu>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Oliver Neukum <oneukum@suse.de>,
Maneesh Soni <maneesh@in.ibm.com>, <gregkh@suse.de>,
<linux-kernel@vger.kernel.org>
Subject: Re: refcounting drivers' data structures used in sysfs buffers
Date: Fri, 9 Mar 2007 14:32:04 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.44L0.0703091343590.2611-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <d120d5000703090934r45c39f74l2a51eda986b1f07b@mail.gmail.com>
On Fri, 9 Mar 2007, Dmitry Torokhov wrote:
> On 3/9/07, Oliver Neukum <oneukum@suse.de> wrote:
> > Am Freitag, 9. März 2007 18:02 schrieb Dmitry Torokhov:
> >
> > > I think we already have all refcounting that is needed. What is
> > > missing is subsystem-provided ->release() hooks for drivers to release
> > > driver-specific resources when a device finally goes away.
> >
> > This is an interesting idea. Is it nice to pass through release()
> > but not open() ?
> >
>
> Not sure if I follow... Generally speaking open is not a mandatory
> operation; however every object in driver model has a release method.
> What I am saying is that certain drivers need to have their disconnect
> method split in 2 parts - one that shuts down the device and second is
> releases resources that might be accesses through sysfs (and other
> kernel parts). That second part will have to be called from
> subsystem's core ->release() method se we need a release() hook.
Dmitry, you're not viewing this correctly.
Adding a new release() callback would solve the problem by creating
another. Drivers need to release their data as soon as possible after
they unbind from a device, not when the device itself goes away. Think
about what would happen if you tried to rmmod a driver. The rmmod process
would block until the device was unregistered.
Oliver, your idea won't work either. Think about what would happen if
someone did
rmmod driver_module </sys/devices/.../attribute_file
The rmmod process would never actually read the attribute, so until it
exited the private data structure would have a positive refcount. But
rmmod can't exit until the driver has been unloaded from memory, and it
can't be unloaded while its data structure is still allocated. Thus we
would end up with deadlock; rmmod would hang forever.
It might be better to keep your earlier patch and fix the deadlock you
mentioned earlier, the one that occurs when unbinding a driver through
sysfs. How exactly does that deadlock work?
Alan Stern
next prev parent reply other threads:[~2007-03-09 19:32 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-08 13:05 refcounting drivers' data structures used in sysfs buffers Oliver Neukum
2007-03-08 16:02 ` Alan Stern
2007-03-09 0:45 ` Oliver Neukum
2007-03-09 16:32 ` Alan Stern
2007-03-09 16:44 ` Oliver Neukum
2007-03-09 17:02 ` Dmitry Torokhov
2007-03-09 17:18 ` Oliver Neukum
2007-03-09 17:34 ` Dmitry Torokhov
2007-03-09 19:32 ` Alan Stern [this message]
2007-03-09 20:05 ` Oliver Neukum
2007-03-09 20:27 ` Alan Stern
2007-03-09 20:39 ` Oliver Neukum
2007-03-09 20:08 ` Alan Stern
2007-03-09 20:48 ` Oliver Neukum
2007-03-10 19:19 ` Alan Stern
2007-03-12 8:54 ` Oliver Neukum
2007-03-12 14:57 ` Alan Stern
2007-03-12 15:23 ` Oliver Neukum
2007-03-12 15:42 ` Dmitry Torokhov
2007-03-12 15:59 ` Oliver Neukum
2007-03-12 16:21 ` Alan Stern
2007-03-12 18:25 ` Oliver Neukum
2007-03-12 19:31 ` Alan Stern
2007-03-12 19:49 ` Oliver Neukum
2007-03-12 20:03 ` Alan Stern
2007-03-12 20:15 ` Oliver Neukum
2007-03-12 20:31 ` Dmitry Torokhov
2007-03-12 20:45 ` Alan Stern
2007-03-12 21:31 ` Richard Purdie
2007-03-13 15:00 ` 2.6.21-rc suspend regression: sysfs deadlock Alan Stern
2007-03-13 18:42 ` Cornelia Huck
2007-03-13 21:20 ` Linus Torvalds
2007-03-14 16:12 ` Alan Stern
2007-03-14 18:43 ` Cornelia Huck
2007-03-14 19:23 ` Alan Stern
2007-03-15 10:27 ` Cornelia Huck
2007-03-15 12:31 ` Hugh Dickins
2007-03-15 13:02 ` Oliver Neukum
2007-03-15 13:22 ` Dmitry Torokhov
2007-03-15 13:59 ` Hugh Dickins
2007-03-15 14:27 ` Alan Stern
2007-03-15 15:32 ` Cornelia Huck
2007-03-15 16:29 ` Hugh Dickins
2007-03-15 16:51 ` Linus Torvalds
2007-03-15 19:50 ` [PATCH] sysfs and driver core: add callback helper, used by SCSI and S390 Alan Stern
2007-03-15 19:51 ` [PATCH] sysfs: reinstate exclusion between method calls and attribute unregistration Alan Stern
2007-03-13 19:00 ` 2.6.21-rc suspend regression: sysfs deadlock Hugh Dickins
2007-03-13 20:09 ` Alan Stern
2007-03-13 20:55 ` Hugh Dickins
2007-03-13 21:08 ` Dmitry Torokhov
2007-03-13 21:20 ` 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=Pine.LNX.4.44L0.0703091343590.2611-100000@iolanthe.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=maneesh@in.ibm.com \
--cc=oneukum@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).