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
next prev 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 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).