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.022 / U:0.644 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site