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. 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. 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
