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]

Message-Id: <1242559101.28127.63.camel@johannes.local>
Date:	Sun, 17 May 2009 13:18:21 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Zdenek Kabelac <zdenek.kabelac@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Oleg Nesterov <oleg@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: INFO: possible circular locking dependency at
 cleanup_workqueue_thread

On Sun, 2009-05-17 at 09:18 +0200, Ingo Molnar wrote:
> Cc:s added. This dependency:

Not sure why you're not adding the cfg80211 maintainer if you think
cfg80211 causes the problem...

> > -> #2 (cfg80211_mutex){+.+.+.}:
> >        [<ffffffff80271a64>] __lock_acquire+0xc64/0x10a0
> >        [<ffffffff80271f38>] lock_acquire+0x98/0x140
> >        [<ffffffff8054e78c>] __mutex_lock_common+0x4c/0x3b0
> >        [<ffffffff8054ebf6>] mutex_lock_nested+0x46/0x60
> >        [<ffffffffa007e66a>] reg_todo+0x19a/0x590 [cfg80211]
> >        [<ffffffff80258f18>] worker_thread+0x1e8/0x3a0
> >        [<ffffffff8025dc3a>] kthread+0x5a/0xa0
> >        [<ffffffff8020d23a>] child_rip+0xa/0x20
> 
> is what sets the dependencies upside down.

I'm also not sure how you arrived at that conclusion, I would be
interested to hear how you did. In any case, it's most definitely not
cfg80211 causing it.

Cf. this, almost identical, lockdep report for example:
http://paste.pocoo.org/show/116240/
The logical conclusion here would be to say that the rtnl is responsible
here...

As you can see from the report, the only thing cfg80211_mutex does is
register a device struct while holding it -- claiming cfg80211 (or rtnl
in the other report which behaves the same) responsibility here because
of that is totally ludicrous -- that would mean you've suddenly changed
all the locking rules so that you can no longer register devices under a
lock that you also need from a work struct executed due to
schedule_work().

I'm not entirely sure yet, but I would think the problem might be a
false positive in the workqueue code -- remember this report only
triggers because cleanup_workqueue_thread() acquires the fake lock for
the workqueue. Maybe it shouldn't do that from the CPU_POST_DEAD
notifier? Oleg, can you help me out here?

johannes

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