Messages in this thread | | | Subject | Re: INFO: possible circular locking dependency at cleanup_workqueue_thread | From | Johannes Berg <> | Date | Fri, 22 May 2009 10:11:09 +0200 |
| |
On Fri, 2009-05-22 at 16:03 +0800, Ming Lei wrote: > 2009/5/20 Johannes Berg <johannes@sipsolutions.net>: > > On Wed, 2009-05-20 at 11:36 +0800, Ming Lei wrote: > > > >> > Anyway, you can have a deadlock like this: > >> > > >> > CPU 3 CPU 2 CPU 1 > >> > suspend/hibernate > >> > something: > >> > rtnl_lock() device_pm_lock() > >> > -> mutex_lock(&dpm_list_mtx) > >> > > >> > mutex_lock(&dpm_list_mtx) > >> > >> Would you give a explaination why mutex_lock(&dpm_list_mtx) runs in CPU2 > >> and depends on rtnl_lock? > > > > Why not? Something is registering a hotplugged netdev. > > It seems dpm_list_mtx is held in kernel_init context, so should not consider > registering a hotplugged netdev, isn't it? > > I am still confused, since rtnl_mutex is held before dpm_list_mtx which > is acquired in kernel_init context. > > [ 562.689476] -> #3 (dpm_list_mtx){+.+.+.}: > [ 562.689480] [<ffffffff8026eae8>] __lock_acquire+0x13a9/0x171c > [ 562.689484] [<ffffffff8026ef5f>] lock_acquire+0x104/0x130 > [ 562.689489] [<ffffffff804ab2f0>] mutex_lock_nested+0x6f/0x36b > [ 562.689493] [<ffffffff803f6395>] device_pm_add+0x4b/0xf2 > [ 562.689499] [<ffffffff803ef382>] device_add+0x498/0x62a > [ 562.689503] [<ffffffff8043fd32>] netdev_register_kobject+0x7b/0x80 > [ 562.689509] [<ffffffff80434761>] register_netdevice+0x2d0/0x469 > [ 562.689514] [<ffffffff80434939>] register_netdev+0x3f/0x4d > [ 562.689519] [<ffffffff806f634f>] loopback_net_init+0x40/0x7d > [ 562.689524] [<ffffffff8042ee79>] register_pernet_device+0x32/0x5f > [ 562.689528] [<ffffffff806fb41a>] net_dev_init+0x143/0x1a1 > [ 562.689533] [<ffffffff80209080>] do_one_initcall+0x75/0x18a > [ 562.689538] [<ffffffff806d0678>] kernel_init+0x138/0x18e > [ 562.689542] [<ffffffff8020c33a>] child_rip+0xa/0x20 > [ 562.689546] [<ffffffffffffffff>] 0xffffffffffffffff
You need to stop looking at the lockdep report. We've strayed far enough from it that it's no longer useful. Anyhow, the kernel_init context here doesn't matter -- what is relevant is that we have device_pm_add being called somewhere inside register_netdev
where register_netdev acquires the rtnl, and device_pm_add acquires dpm_list_mtx so we get this dependency of the two which I mapped onto CPU 2.
The fact that this is in kernel_init isn't significant, that's because the network device is built-in or whatever, if you hotplug a USB network device you get the same chain of events starting from USB.
johannes [unhandled content-type:application/pgp-signature] | |