linux-kernel - Re: INFO: possible circular locking dependency at cleanup_workqueue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 May 2009 10:11:09 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	Oleg Nesterov <oleg@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Zdenek Kabelac <zdenek.kabelac@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: INFO: possible circular locking dependency at 
 cleanup_workqueue_thread

On Fri, 2009-05-22 at 16:03 +0800, Ming Lei wrote:
> 2009/5/20 Johannes Berg <johannes@...solutions.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

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)