linux-kernel - Re: irda rmmod lockdep trace.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	13 Mar 2007 16:18:06 -0000
From:	"Samuel Ortiz" <samuel@...tiz.org>
To:	davem@...emloft.net
CC:	"davej@...hat.com" <davej@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>
Subject: Re: irda rmmod lockdep trace.


On 3/12/2007, "David Miller" <davem@...emloft.net> wrote:

>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?
I considered that solution as well, and thought that it would then
prevent the hasbin locks from being ever validated by lockdep.
OTOH, the hashbin code is not likely to change anytime soon and is
currently validated.
Also, you will eventually push this code upstream, so I'd rather go for
that fix ;-)

Thanks for the comment.

Cheers,
Samuel.
-
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/