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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/