From: Waiman Long <longman@redhat.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Frederic Weisbecker <frederic@kernel.org>,
Danilo Krummrich <dakr@kernel.org>, Tejun Heo <tj@kernel.org>,
Jinhui Guo <guojinhui.liam@bytedance.com>,
Waiman Long <longman@redhat.com>
Subject: [PATCH v4 1/2] PCI: Suppress false positive lockdep warning in pci_call_probe()
Date: Tue, 9 Jun 2026 14:03:14 -0400 [thread overview]
Message-ID: <20260609180315.850637-2-longman@redhat.com> (raw)
In-Reply-To: <20260609180315.850637-1-longman@redhat.com>
local_pci_probe() and hence pci_call_probe() can be called recursively,
e.g. when vmd_probe() calls .probe() for devices in the new hierarchy
below VMD or a PF .probe() enables VFs and calls .probe() for them. If
the recursive calls are done indirectly via workqueue kworker, a lockdep
recursive warning like the following can be produced.
============================================
WARNING: possible recursive locking detected
7.1.0-rc6-test+ #1 Not tainted
--------------------------------------------
kworker/52:1/1593 is trying to acquire lock:
ffffc9001498f708 ((work_completion)(&arg.work)){+.+.}-{0:0}, at: start_flush_work+0x3e9/0x9a0
but task is already holding lock:
ffffc9001498fd10 ((work_completion)(&arg.work)){+.+.}-{0:0}, at: process_one_work+0xd4c/0x1390
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock((work_completion)(&arg.work));
lock((work_completion)(&arg.work));
*** DEADLOCK ***
This is a false positive warning due to the limitation on the number
of distinct lockdep keys allowed. The same lockdep key is used when the
INIT_WORK_ONSTACK() macro is called in pci_call_probe(). So when a work
function queued by pci_call_probe() calls into pci_call_probe() again
and another work function is queued and flushed, the lockdep warning
will be displayed. This can be suppressed by registering a dynamic key
and used it whenever the current task is a wq kworker.
Dynamic lockdep keys are limited finite resources and they should be
used only when really necessary.
Signed-off-by: Waiman Long <longman@redhat.com>
---
drivers/pci/pci-driver.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index e3f59001785a..bc8c0f061072 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -394,8 +394,21 @@ static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev,
error = local_pci_probe(&ddi);
} else {
struct pci_probe_arg arg = { .ddi = &ddi };
+ struct lock_class_key key;
+
+ /*
+ * A nested pci_call_probe() via a work func will produce a
+ * false positive lockdep recursive locking warning. Use
+ * lockdep_register_key() to provision a dynamic key to
+ * suppress this warning when the current task is a wq kworker.
+ */
+ if (current->flags & PF_WQ_WORKER) {
+ lockdep_register_key(&key);
+ INIT_WORK_ONSTACK_KEY(&arg.work, local_pci_probe_callback, &key);
+ } else {
+ INIT_WORK_ONSTACK(&arg.work, local_pci_probe_callback);
+ }
- INIT_WORK_ONSTACK(&arg.work, local_pci_probe_callback);
/*
* The target election and the enqueue of the work must be within
* the same RCU read side section so that when the workqueue pool
@@ -422,6 +435,8 @@ static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev,
}
destroy_work_on_stack(&arg.work);
+ if (current->flags & PF_WQ_WORKER)
+ lockdep_unregister_key(&key);
}
dev->is_probed = 0;
--
2.54.0
next prev parent reply other threads:[~2026-06-09 18:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 18:03 [PATCH v4 0/2] PCI: Suppress lockdep warning & make pci_call_probe() more efficient Waiman Long
2026-06-09 18:03 ` Waiman Long [this message]
2026-06-09 18:03 ` [PATCH v4 2/2] PCI: Call local_pci_probe() directly in pci_call_probe() if affined to the right node Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260609180315.850637-2-longman@redhat.com \
--to=longman@redhat.com \
--cc=bhelgaas@google.com \
--cc=dakr@kernel.org \
--cc=frederic@kernel.org \
--cc=guojinhui.liam@bytedance.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®