On 07.02.2022 15:27, Roger Pau Monné wrote: > On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote: >> 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. > > I'm confused. If we use a per-domain rwlock approach there would be no > need to lock tmp again in modify_bars, because we should hold the > rwlock in write mode, so there's no ABBA? > > We will have however to drop the per domain read and vpci locks and > pick the per-domain lock in write mode.
Well, yes, with intermediate dropping of the lock acquiring in write mode can be done in modify_bars(). I'm not convinced (yet) that such intermediate dropping is actually going to be okay. Jan