Messages in this thread | | | Date | Mon, 12 Mar 2007 16:49:21 -0700 (PDT) | Subject | Re: irda rmmod lockdep trace. | From | David Miller <> |
| |
From: Samuel Ortiz <samuel@sortiz.org> Date: Mon, 12 Mar 2007 02:38:43 +0200
> On Sat, Mar 10, 2007 at 07:43:26PM +0200, Samuel Ortiz wrote: > > Hi Dave, > > > > On Thu, Mar 08, 2007 at 05:54:36PM -0500, Dave Jones wrote: > > > modprobe irda ; rmmod irda in 2.6.21rc3 gets me the spew below.. > > Well it seems that we call __irias_delete_object() from hashbin_delete(). Then > > __irias_delete_object() calls itself hashbin_delete() again. We're trying to > > get the lock recursively. > Looking at the code more carefully, this seems to be a false positive: > iriap_cleanup and and __irias_delete_object are taking 2 different locks from > 2 different hashbin instances. The locks belong to the same lock class but > they are hierarchically different. We need to tell the validator about it and > the following patch does that. Comments are welcomed as I'm planning to push > it to netdev soon:
I would strongly caution against adding any run-time overhead just to cure a false lockdep warning. Even adding a new function argument is too much IMHO.
Make the cost show up for lockdep only, perhaps by putting each hashbin lock into a seperate locking class?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |