From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: hotplug remove vs. device driver close
Date: Wed, 02 Jun 2004 23:28:51 +0000 [thread overview]
Message-ID: <20040602232851.GA24169@kroah.com> (raw)
In-Reply-To: <20040602181455.C17544@forte.austin.ibm.com>
On Wed, Jun 02, 2004 at 06:14:55PM -0500, linas@austin.ibm.com wrote:
>
> Hi,
>
> We are hitting a situation where we are hot-plug removing a pci card before
> closing the device driver. This seems to lead to kernel memory leaks if not
> outright crashes. I'm trying to understand what the correct solution to this
> is supposed to be.
To paraphrase from the PCI Hotplug spec, "DO NOT DO THAT!"
> For example: 'ifup eth0' and 'ifdown eth0' are what usually cause an ethernet
> device driver to be opened/closed. Seprately, we have a userland tool that
> can be used to power off the pci slot, and thus perform a hotplug unconfigure
> in the kernel (i.e. calls pci_remove_bus_device()). Thus, the sysadmin
> currently has the power to hot-remove a device without first closing the
> device driver. Surely, this is bad. (Right?) But how is this supposed to
> be handled?
Again, do not do that.
> Please don't tell me that a good sysadmin should never do that ... in the
> hothouse of the server room, crazy stuff happens and it should not result
> in a server crash so easily ...
Tough, do not do that.
That being said, a lot of the PCI drivers can recover from this as they
also work for PCMCIA devices, and they need to be able to handle this.
It is possible, and pretty simple to fix within the driver itself.
> I'm hoping that the answer also isn't that 'the hotplug scripts should
> do that', since hotplug scripts can be buggy, or can crash for many reasons;
> such events shouldn't bring down the kernel.
No, it's not a hotplug script issue.
> So I conclude two possibilities:
>
> -- All device drivers should watch for hotplug remove, and close themselves
> down in such an event
No, they should watch for errors when trying to read and write from
their devices and if that happens, handle it properly. The kernel will
tell them at some time that the device is really gone by calling the
disconnect() callback.
> -- The syscall that allows the pci slot to be powered off should also
> go through the steps of closing the device driver first.
No. Read the PCI Hotplug spec.
> Is there another possibility? What's the right way of handling this?
See above.
What driver is dying for you? It should be quite easy to fix.
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-02 23: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 [this message]
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
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=20040602232851.GA24169@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).