lkml.org 
[lkml]   [2007]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: irda rmmod lockdep trace.
From
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/

\
 
 \ /
  Last update: 2007-03-13 00:51    [W:0.051 / U:21.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site