Thread (14 messages) flat view 14 messages, 8 authors, 2013-04-19

Re: hitting lockdep warning as of too early VF probe with 3.9-rc1

From: Ming Lei <hidden>
Date: 2013-03-07 02:03:55

On Thu, Mar 7, 2013 at 4:54 AM, Or Gerlitz [off-list ref] wrote:
On Wed, Mar 6, 2013 at 4:43 AM, Ming Lei [off-list ref] wrote:
quoted
You are adding one new PCI device inside another PCI device's probe(),
so the new device will be probed, since PCI probe() is scheduled by
work_on_cpu, then cause flush_work() called inside worker function,
which might be a real deadlock.
So if I understand correct, you recommend to somehow avoid this nested probing?
Yes, you might need to avoid the nested probing in your driver.
quoted
I am wondering why this commit can cause the problem, since the PCI
device will be probed with its driver if there is one driver for it. There is no
any limit on when the driver should be loaded into system, either before
device is added or after.
FWIW to undertstanding the issue - the same driver (mlx4_core) is used
by the PF and VF, so the VF driver is already loaded at the time its
been added as new PCI device.
quoted
From driver core view, looks no wrong things are found.
So this got me confused, you pointed on possible deadlock, are you
saying the deadlock wouldn't be the result of how the driver code is
going nor the commited we bisected?
My commit only affects the driver loading path, but your warning
is hit in driver probe path triggered by device addition, so the lockdep
warning should still be triggered without my commit since the two paths
are totally independent, right?

Thanks,
--
Ming Lei
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help