Re: PCI: Prevent device lock leak during bus reset

[Hongtao Zhang]

Hi Bjorn,

Gentle ping on this RFC.

Sashiko's review points out that pci_try_reset_bus(), pci_slot_reset()
and pci_try_reset_slot() have the same problem, since
__pci_bus_trylock(), __pci_bus_lock() and __pci_bus_unlock() also walk
bus->devices independently for locking and unlocking. This matches the
limitation I noted in the commit message.

The review also mentions a possible use-after-free. In those unpatched
paths, bus->devices is walked without pci_bus_sem and without taking
device references, so a device removed and freed concurrently could be
accessed during the walk. With the snapshot approach this is avoided:
the snapshot is taken under pci_bus_sem, a reference is held on every
device in it, and both locking and unlocking use only the snapshot. A
removed device therefore cannot be freed until the reset completes.

Before extending this to the other paths, I would like to confirm the
direction. I see two options:

1. Extend the snapshot approach to the slot and try-reset paths. The
   change stays small and local, but a device added after the snapshot
   may still be reset without its device lock held.

2. Prevent topology changes for the whole reset. This would also cover
   devices added after the snapshot, but it needs a lock held across the
   reset and care to avoid deadlocks with hotplug and AER recovery.

I lean towards option 1 as a fix that is easier to backport, with
option 2 possibly done separately later. Does that sound reasonable, or
should I go with option 2 directly?

Thanks,
Hongtao