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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
