[PATCH] PCI: ensure the PCI device is locked over ->reset_notify calls

Bjorn Helgaas helgaas at kernel.org
Wed May 31 09:51:31 PDT 2017


On Wed, May 31, 2017 at 06:58:48AM +0200, Christoph Hellwig wrote:
> On Tue, May 30, 2017 at 05:28:44PM -0500, Bjorn Helgaas wrote:
> > [+cc Alex]
> > 
> > On Tue, May 23, 2017 at 07:42:02AM +0200, Christoph Hellwig wrote:
> > > Without this ->notify_reset instance may race with ->remove calls,
> > 
> > Do you mean the .reset_notify() method in struct pci_error_handlers?
> > I don't see a "notify_reset" symbol.
> 
> Yes.
> 
> > Can you elaborate on exactly how this race happens?  I'm trying to
> > figure out whether this is also a problem or potential problem with
> > other reset paths like pci_try_reset_function(), pci_reset_bus(),
> > pci_try_reset_bus(), pci_reset_slot(), and pci_try_reset_slot().
> > 
> > What does the race look like when it happens?  Oops, panic, etc?
> > 
> > Can this also be triggered via the sysfs "reset" file?
> 
> Here is the original bug report:
> 
> http://lists.infradead.org/pipermail/linux-nvme/2017-May/010345.html
> 
> the issue is triggered through sysfs.

Thanks.

Do you have any thoughts on whether the paths I mentioned above are
also susceptible?

I don't want to apply a patch that fixes one issue while leaving
similar ones unfixed.

Bjorn



More information about the Linux-nvme mailing list