RFC pci: Rework is_added race fix and address bridge enable races
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest6 patches 22 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/6 | Revert "PCI: Fix is_added/is_busmaster race condition"arch/ arch/ arch/ +6 more | +12 | 10 replies | |
| 2/6 | pci: Set pci_dev->is_added before calling device_adddrivers/ | +2 | 5 replies | |
| 3/6 | pci: Remove priv_flags and use dev->error_state for "disconnected" statusdrivers/ drivers/ drivers/ +2 more | +11 | 1 reply | |
| 4/6 | pci: Add a mutex to pci_dev to protect device statedrivers/ include/ | +18 | 0 replies | |
| 5/6 | pci: Protect the enable/disable state of pci_dev using the state mutexdrivers/ | +35 | 6 replies | |
| 6/6 | pci: Protect is_busmaster using the state lockdrivers/ include/ | +10 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/6] pci: Rework is_added race fix and address bridge enable races
This is really two series but since they conflict a bit separately here they are in one:
First we undo the mess of those atomic priv_flags. The atomicity doesn't provide any security since there's no locking against the other state pertaining to those flags, it only protects the flags themselves.
The is_added mess is fixed much more simply by moving the assignment of the flag to before we start the driver. This is in line with the rest of the PCI code: until bound to the device model, we are essentially assuming a single threaded environment. is_added is a flag that is logically owned by that part of the PCI code, and thus should be set and cleared within that "safer" environment.
This removes the horrid relative includes in the powerpc code as well.
The second part aims at fixing the enable/disable/set_master races, and does so by providing a framework for future device state locking issues.
It introduces a pci_dev->state_mutex which is used at a lower level than the device_lock (the device lock isn't suitable, as explained in the cset comments) and uses it to protect enablement and set_master.