On Mon, Sep 27, 2021 at 03:22:24PM -0300, Jason Gunthorpe wrote: > On Mon, Sep 27, 2021 at 09:17:19PM +0300, Leon Romanovsky wrote: > > > > The point is to all out a different locking regime that relies on the > > > sriov enable/disable removing the VF struct devices > > > > You can't avoid trylock, because this pci_get_sriov_pf_devdata() will be > > called in VF where it already holds lock, so attempt to take PF lock > > will cause to deadlock. > > My whole point is we cannot use the device_lock *at all* and a > pci_get_sriov_pf_devdata() would not have it. Right > > Instead it would have some test to confirm that the 'current' struct > device is a VF of the 'target' struct device and thus the drvdata > must be valid so long as the 'current' struct device hasn't completed > remove. I'm curious to see how can you implement it without holding VF lock. > > It is a completely different locking scheme than device lock. It also > relies on the PF driver placing the sriov enable/disable 'locks' in > the correct place relative to their drvdata's. > > Jason
