All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: hotplug remove vs. device driver close
Date: Thu, 03 Jun 2004 19:28:17 +0000	[thread overview]
Message-ID: <20040603192817.GC23564@kroah.com> (raw)
In-Reply-To: <20040602181455.C17544@forte.austin.ibm.com>

On Thu, Jun 03, 2004 at 12:23:04PM -0700, Don Fry wrote:
> > > > We make no such guarantee.  As I stated, the Cardbus/PCMCIA handle this
> > > > quite easily, so it is pretty simple to fix up a PCI driver to also
> > > > handle this.
> > > >
> > > > But the main answer is that the PCI Hotplug spec states that the OS does
> > > > NOT have to protect for this happening to regular PCI devices.
> > >
> > > So if I understand what you are saying: if the OS crashes because of
> > > a sysadmin error or a script error during pci hotplug remove, that's
> > > considered OK?
> > 
> > As sysadmin I can delete your whole root fs, and reboot the box into
> > obvilion.  Are you considering changing this ability too?  :)
> > 
> > If you are really worried about this, then look into a different
> > permisssion model for Linux like SELinux.
> > 
> > Or you can simply fix up your PCI driver to properly handle reading all
> > FF when the device has been removed.  That seems to be what you need to
> > do to solve this for your small subset of drivers on your platform,
> > correct?
> > 
> 
> The pcnet32 driver tries to do the 'right thing' when it reads 0xffff,
> but that does not include doing a 'close' prior to being removed.  The
> driver could keep some state around so that if its remove routine was
> called without close first, it would cleanup, but I don't know of any
> network driver that does this.
> 
> The remove with a close is where the leak/crash might occur.

That's up to the upper layer, above the network driver to do, right?
It's the same way for all USB and SCSI/block devices.

Remember, the driver isn't unloaded at device removal time, it should
always be bound to memory until the userspace "open" goes away.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2004-06-03 19:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-02 23:14 hotplug remove vs. device driver close linas
2004-06-02 23:28 ` Greg KH
2004-06-03  1:40 ` Anton Blanchard
2004-06-03 16:20 ` Greg KH
2004-06-03 18:50 ` linas
2004-06-03 19:02 ` Greg KH
2004-06-03 19:23 ` Don Fry
2004-06-03 19:28 ` Greg KH [this message]
2004-06-03 19:34 ` linas
2004-06-03 19:39 ` linas
2004-06-03 20:02 ` Don Fry
2004-06-03 20:39 ` Greg KH
2004-06-03 22:25 ` linas
2004-06-04  3:58 ` Benjamin Herrenschmidt
2004-06-04 16:24 ` Greg KH
2004-06-04 17:26 ` linas

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=20040603192817.GC23564@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-hotplug@vger.kernel.org \
    /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.