Re: [RFC] Observed lockdep circular dependency in SR-IOV paths

["Alex Williamson" <alex@shazbot.org>]

On Mon, Apr 6, 2026, at 4:34 PM, Jason Gunthorpe wrote:
> On Tue, Mar 31, 2026 at 10:23:06AM -0700, Raghavendra Rao Ananta wrote:
>> Hi Alex,
>> 
>> While running the vfio_pci_sriov_uapi_test [1] on a CONFIG_LOCKDEP
>> enabled kernel (7.0-rc1), we observed the following lockdep circular
>> locking dependency warning:
>
> This loos more like a class issue, the locks used by the VF driver are
> different than the locks used by the PF driver, and even though the
> devsets are shared a devset should never have both the PF and VF.
>
> Maybe shifting memory_lock into a different lock class for VFs is
> enough.
>
> However, I think it is a bad idea to hold the memory_lock while
> probing a device, I'd prefer to revisit f4162eb1e2fc ("vfio/pci:
> Change the PF power state to D0 before enabling VFs") and change it's
> logic to rely on a private flag instead of pci_num_vf()
>
> Then we don't need to hold the lock any longer than just setting the
> flag.

I agree, that's cleaner, only hold the write-lock on memory_lock in vfio_pci_core_sriov_configure() to bring the device to D0 and to set a flag on the PF vdev.  That flag would replace the pci_num_vfs() test in vfio_pci_set_power_state().  The flag is cleared without memory_lock if pci_enable_sriov() fails or after pci_disable_sriov().

It's a nice compartmentalized fix.  The lockdep splat is a false positive, but this would eliminate the memory_lock -> work_completion arc of the detection.  Thanks,

Alex