linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: How does Linux handle PCI-E Surprise unplug?
Date: Thu, 18 Feb 2010 14:52:46 +0000	[thread overview]
Message-ID: <20100218145246.GA15714@kroah.com> (raw)
In-Reply-To: <8506939B503B404A84BBB12293FC45F606B883BA@emailbng3.jnpr.net>

On Thu, Feb 18, 2010 at 11:35:33AM +0530, Rajat Jain wrote:
> Hi,
> 
> I'm keen to understand how the Linux kernel handles surprise removal of
> a device, from a PCI-e slot that supports "Hot-plug Surprise" removal
> (in slot capabilities). 
> 
> Consider that the device in the slot is working normally, with its
> driver attached to the device, and is doing all sorts of read / write
> operations on the device registers that have been mapped into the PCI
> memory space. Now when that device is suddenly plugged out (and thus its
> registers suddenly disappear from the PCI memory space), the device
> driver is still unaware as it is doing the register reads / writes on
> the device. At this point, IMHO any attempt to access the device
> registers will result in an exception (BUS error?) as the device is
> gone. Correct?

The driver will suddenly start reading all 0xff and will then need to
abort whatever it was doing.  Usually all drivers handle this just fine
today, as this is what they needed to do when they were pccard devices.
Nothing new here at all.

> From what I understood from the "pciehp.ko" code, it seems that on
> detecting that a device has been plugged out, pciehp_disable_slot() is
> called only in workqueue context (that will happen later). This would
> lead to removal of the device from the PCI hierarchy in the kernel data
> structures, and ultimately the driver will also be detached. 

Yes.

> But my question is that it may be too late for all of the above to
> happen, and the driver code may still get a chance to run and continue
> execution from where it was interrupted (accessing device registers) due
> to surprise removal interrupt. And this is bound to break things. So
> what am I missing here?

Nothing, the driver individually needs to handle the fact that it might
at any time, start getting invalid data.  If it doesn't, it needs to be
fixed.  Do you have a driver that does not handle this properly?

thanks,

greg k-h

  reply	other threads:[~2010-02-18 14:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-18  6:17 How does Linux handle PCI-E Surprise unplug? Rajat Jain
2010-02-18 14:52 ` Greg KH [this message]
2010-02-19  4:13 ` Rajat Jain
2010-02-19  4:27 ` Greg KH
2010-02-19  6:41 ` Hidetoshi Seto
2010-03-08  7:23 ` Rajat Jain
2010-03-08  8:24 ` Kenji Kaneshige
2010-03-08 22:49 ` Grant Grundler

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=20100218145246.GA15714@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).