[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