[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070312.164921.71090866.davem@davemloft.net>
Date: Mon, 12 Mar 2007 16:49:21 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: samuel@...tiz.org
Cc: davej@...hat.com, linux-kernel@...r.kernel.org, mingo@...hat.com
Subject: Re: irda rmmod lockdep trace.
From: Samuel Ortiz <samuel@...tiz.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists