On 07.02.2022 14:53, Oleksandr Andrushchenko wrote: > On 07.02.22 14:46, Roger Pau Monné wrote: >> I think the per-domain rwlock seems like a good option. I would do >> that as a pre-patch. > It is. But it seems it won't solve the thing we started this adventure for: > > With per-domain read lock and still ABBA in modify_bars (hope the below > is correctly seen with a monospace font): > > cpu0: vpci_write-> d->RLock -> pdev1->lock -> > rom_write -> modify_bars: tmp (pdev2) ->lock > cpu1: vpci_write-> d->RLock pdev2->lock -> cmd_write -> modify_bars: > tmp (pdev1) ->lock > > There is no API to upgrade read lock to write lock in modify_bars which could > help, > so in both cases vpci_write should take write lock.
Hmm, yes, I think you're right: It's not modify_bars() itself which needs to acquire the write lock, but its (perhaps indirect) caller. Effectively vpci_write() would need to take the write lock if the range written overlaps the BARs or the command register. Jan
