public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Greg KH <greg@kroah.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Patrick Mochel <mochel@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: Flaw in the driver-model implementation of attributes
Date: Mon, 16 Jun 2003 18:20:03 +0100	[thread overview]
Message-ID: <20030616182003.D13312@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20030616170825.GB24986@kroah.com>; from greg@kroah.com on Mon, Jun 16, 2003 at 10:08:26AM -0700

On Mon, Jun 16, 2003 at 10:08:26AM -0700, Greg KH wrote:
> Then don't let your module unload until _all_ instances of your
> structures are gone.  You can tell if this is true or not, it's just up
> to the implementor :)

Greg, I believe Alan does have a valid concern.  Eg, how is the following
handled?

- PCI device driver module is loaded
- device driver gets handed a pci device
- device driver attaches a file to the struct device corresponding to the
  PCI device.
- userspace opens new file (this does not increment the device drivers
  use count.)
- device driver is rmmod'd
- device driver removes its references to the pci device
- device driver unloads
- user reads from opened file.

> Look at the new pcmcia code for just such an example.

In the pcmcia case, we effectively own the object (class device) we're
attaching the files to, so we can ensure that the module is not unloaded
until the class device files are closed and all references to the object
are gone.

IMO, if you don't own the object (and therefore don't know its lifetime),
you shouldn't be adding sysfs or device model attributes of any kind to
that object.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


  reply	other threads:[~2003-06-16 17:06 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-15 16:42 Flaw in the driver-model implementation of attributes Alan Stern
2003-06-15 17:40 ` Jeremy Fitzhardinge
2003-06-16 14:05   ` Alan Stern
2003-06-16 17:08 ` Greg KH
2003-06-16 17:20   ` Russell King [this message]
2003-06-16 17:54     ` Alan Stern
2003-06-16 18:00       ` Patrick Mochel
2003-06-16 18:03       ` viro
2003-06-16 18:23         ` Alan Stern
2003-06-16 18:38           ` Patrick Mochel
2003-06-16 19:06             ` Alan Stern
2003-06-16 18:00     ` Martin Diehl
2003-06-16 18:15       ` viro
     [not found] <20030616194446.H13312@flint.arm.linux.org.uk>
2003-06-16 19:36 ` Alan Stern
2003-06-16 20:49   ` Patrick Mochel
2003-06-16 21:29     ` Alan Stern
2003-06-16 22:43       ` Patrick Mochel
2003-06-17 19:49         ` Alan Stern
2003-06-18  1:38           ` Kevin P. Fleming
2003-06-16 23:36       ` Greg KH
2003-06-17 17:29         ` Alan Stern
2003-06-17 17:33           ` Greg KH
2003-06-17 20:20             ` Alan Stern
  -- strict thread matches above, loose matches on Subject: below --
2003-06-18  3:44 Perez-Gonzalez, Inaky
2003-06-18  4:18 ` viro
2003-06-18  7:48 Perez-Gonzalez, Inaky
2003-06-18  8:12 ` viro
2003-06-18 14:32   ` Alan Stern
2003-06-18 17:15     ` Greg KH
2003-06-18 19:50       ` Alan Stern
2003-06-19 16:42         ` Patrick Mochel
2003-06-19 21:18           ` Alan Stern
2003-06-19 14:13       ` Alan Stern
2003-06-19 17:07         ` Patrick Mochel
2003-06-19 21:14           ` Alan Stern
2003-06-19 21:31             ` Greg KH
2003-06-20 14:22               ` Alan Stern
2003-06-20 18:32                 ` Greg KH
2003-07-02 22:12                   ` Greg KH
2003-07-03 14:51                     ` Alan Stern
2003-06-19 17:26         ` Mike Anderson
2003-06-18 19:52 Perez-Gonzalez, Inaky
2003-06-19  0:06 Clayton Weaver
2003-06-19  0:20 ` Kevin P. Fleming
2003-06-19 16:46   ` Patrick Mochel
2003-06-19 21:18 Perez-Gonzalez, Inaky

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=20030616182003.D13312@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox