linux-kernel - Re: [PATCH 000 of 4] Introduction

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]

Message-ID: <20061011085255.GA6051@elte.hu>
Date:	Wed, 11 Oct 2006 10:52:55 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	NeilBrown <neilb@...e.de>
Cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Al Viro <viro@....linux.org.uk>
Subject: Re: [PATCH 000 of 4] Introduction


* NeilBrown <neilb@...e.de> wrote:

> Following 4 patches address issues with lockdep, particularly around 
> bd_mutex.
> 
> They are against 2.6.18-mm3 and do *not* apply against -linus as -mm 
> already has some changes to the handling of bd_mutex nesting.  2-4 
> probably apply on top of -linus plus 
> -mm/broken-out/remove-the-old-bd_mutex-lockdep-annotation.patch
> 
> I believe they are probably ok for 2.6.19.

agreed.

they look quite nice in that they also simplify the underlying locking. 
(instead of just trying to clone whatever locking yuckiness there is, 
into the lockdep space.)

> The last fixes a tangentially related lockdep problem in md - there is 
> a false relationship between bd_mutex and md->reconfig_mutex which 
> needs to be clarified.

> md_open takes ->reconfig_mutex which causes lockdep to complain. This 
> (normally) doesn't have deadlock potential as the possible conflict is 
> with a reconfig_mutex in a different device.
>
> I say "normally" because if a loop were created in the array->member 
> hierarchy a deadlock could happen.  However that causes bigger 
> problems than a deadlock and should be fixed independently.

ok to me. Sidenote: shouldnt we algorithmically forbid that "loop" 
scenario from occuring, as that possibility is what causes lockdep to 
complain about the worst-case scenario?

	Ingo
-
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/