On Mon, Nov 11, 2024 at 06:58:40PM +0100, Sebastian Ott wrote:
> I stumbled over this lockdep splat during pci hotplug:
> [ 26.016648] ======================================================
> [ 26.019646] WARNING: possible circular locking dependency detected
> [ 26.022785] 6.12.0-rc6+ #176 Not tainted
> [ 26.024776] ------------------------------------------------------
> [ 26.027909] irq/50-pciehp/57 is trying to acquire lock:
> [ 26.030559] ffff0000c02ad700 (&ctrl->reset_lock){.+.+}-{3:3}, at: pciehp_configure_device+0xe4/0x1a0
> [ 26.035423] [ 26.035423] but task is already holding lock:
> [ 26.038505] ffff800082f819f8 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x24/0x38
> [ 26.043512] [ 26.043512] which lock already depends on the new lock.
[...]
> I don't think that this could actually happen since this is only called by a
> single irq thread
Correct, it's a false positive, see this earlier analysis from Oct 2023:
https://lore.kernel.org/all/20231015093722.GA11283@xxxxxxxxx/
> but this splat is kinda annoying and
> pciehp_configure_device() doesn't seem to do much that
> needs the reset_lock. How about this?
> ---->8
> [PATCH] pciehp: fix lockdep warning
>
> Call pciehp_configure_device() without reset_lock being held to
> fix the following lockdep warning. The only action that seems to
> require the reset_lock is writing to ctrl->dsn, so move that to
> the caller that holds the lock.
The point is to prevent a slot reset while the bus is being enumerated.
It's not just for reading the Device Serial Number. So unfortunately
it's not that simple.
Thanks,
Lukas
