hotplug remove vs. device driver close
Greg KH
greg at kroah.com
Fri Jun 4 05:28:17 EST 2004
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
** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc64-dev
mailing list