Re: [PATCH] PCI device list locking

[Martin Mares <mj@ucw.cz>]

Hello!

When I was actively maintaining the PCI subsystem, I was becoming increasingly
unhappy about the lack of locking, but I was unable to find any simple
strategy which wouldn't require rewriting of many drivers.

Lots of drivers still use the old probing interface (pci_find_*). Possible
solutions: either add locking around probing loop in all drivers or (maybe
better) convert all drivers to the new interface and drop the old one
completely.

> Unless I missed something even a semaphore might deadlock then:
> 
> think of a pci driver for bridge-type device which has devices already 
> attached when probed - for example cardbus (or hotplug) controller with
> device on the downside. If the devices are found during probe(), the 
> driver might want to just add them in one go.

Device addition is not a hard problem, it just suffices to define the locking
rules a bit better to avoid deadlock. Removal is much worse -- you need to
ensure not only nobody is working with the list, but also that nobody is
using the pci_dev being removed.

Maybe we could do it this way:  (assuming all drivers use the new interface)

  o  Introduce a global semaphore guarding all PCI lists (the global
     device list and all per-bus linkages). Add pci_{un,}lock_lists().
     [Using any r/w-thing is probably pointless as both reads and writes
     to the list are very rare.]

  o  Make pci_for_each_dev call pci_{un,}lock_lists().

  o  Define that for calling pci_{insert,remove}_device() the lists
     must be locked by the caller.

  o  Define that if you want to access any pci_dev, you must either have
     the lists locked or be the owner of the device (pci_dev->driver).

  o  Define that when you are walking the list by pci_for_each_dev(),
     you can remove any device except the current one.

Unless I've missed anything, these rules seem to cover all the cases
needed including probe/remove functions adding/removing devices on the
downside of a bridge.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
For every complex problem, there's a solution that is simple, neat and wrong.

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel