Re: INFO: possible circular locking dependency at cleanup_workqueue_thread

[Ingo Molnar <mingo@elte.hu>]

* Johannes Berg <johannes@sipsolutions.net> wrote:

> 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...

Oversight and lack of time. Why are you asking it in such an edgy 
way instead of just addig the Cc:s? Why do you want to set a 
negative tone in the thread? Do you think it results in a faster 
resolution?

> > > -> #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. [...]

( no strong reason, i looked for 10 seconds and this is what popped
  up. You looked a bit deeper and found something different. )

> [...] 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

We can also remove the workqueue lockdep annotations if the false 
positive rate is too high.

	Ingo