Re: INFO: possible circular locking dependency atcleanup_workqueue_thread

[Johannes Berg]

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

Attachment: signature.asc
Description: This is a digitally signed message part