lkml.org 
[lkml]   [2008]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.6.24-rc7 lockdep warning when poweroff
From
Date

On Tue, 2008-01-15 at 13:39 +0100, Johannes Berg wrote:
> > > To make sure now:
> > > same key - different name - BAD
> > > same key - same name - OK
> > > different key - same name - OK
> >
> > Strictly speaking one can do that, although I would recommend against it
> > - it leads to confusion as to which lock got into trouble when looking
> > at lockdep/stat output.
>
> True, but I don't see a good way to avoid that. Similar things also
> happen with
>
> mutex_init(&priv->mtx);
>
> for example, no?

Yeah, it happens, I tend to 'fix' them when I encounter it though,
sometimes by just slightly altering the expression. It helps when
grepping the tree.

> > > mac80211 for example wants to allocate a (single-threaded) workqueue for
> > > each hardware that is plugged in and wants to call it by the hardware
> > > name.
> >
> > Right, that would require a new key for each instance.
>
> Except, how could I do that though? Keys are required to be static, so I
> can't have the object as the key. In any case, I don't think it matters
> much because the workqueues are per-hardware but all have similar users,
> I think that the other users here probably behave similarly.

Yeah, I think so too, but never underestimate the creativity of driver
authors:-)

> > > If you think the patch is a correct way to solve the problem I'll submit
> > > it formally and it should then be included in 2.6.24 to avoid
> > > regressions with the workqueue API (the workqueue lockup detection was
> > > merged early in 2.6.24.)
> >
> > The patch looks ok, one important thing to note is that it means that
> > all workqueues instantiated by the same __create_workqueue() call-site
> > share lock dependency chains - I'm unsure if that might get us into
> > trouble or not.
>
> It doesn't seem to have so far ;) I don't think it should. If some code
> allocates a per-instance workqueue that's much like having an inode lock
> or so.

We had to split up the inode lock to per filesystem classes, just
because the lock chains were conflicting between them...

> > Me and Ingo :-)
>
> Alright, I'll write a patch description and send it in a minute.

Great, thanks for the effort.



\
 
 \ /
  Last update: 2008-01-15 13:49    [W:0.595 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site