Re: lockdep warning in pciehp

[Lukas Wunner <lukas@wunner.de>]

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@wunner.de/


> 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