From: Ingo Molnar <mingo@elte.hu>
To: NeilBrown <neilb@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [PATCH 000 of 4] Introduction
Date: Wed, 11 Oct 2006 10:52:55 +0200 [thread overview]
Message-ID: <20061011085255.GA6051@elte.hu> (raw)
In-Reply-To: <20061011155522.7915.patches@notabene>
* NeilBrown <neilb@suse.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
next prev parent reply other threads:[~2006-10-11 9:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-11 6:09 [PATCH 000 of 4] Introduction NeilBrown
2006-10-11 6:09 ` [PATCH 001 of 4] Remove lock_key approach to managing nested bd_mutex locks NeilBrown
2006-10-11 6:09 ` [PATCH 002 of 4] Simplify some aspects of bd_mutex nesting NeilBrown
2006-10-11 6:09 ` [PATCH 003 of 4] Use mutex_lock_nested for bd_mutex to avoid lockdep warning NeilBrown
2006-10-11 6:09 ` [PATCH 004 of 4] Avoid lockdep warning in md NeilBrown
2006-10-11 8:44 ` [PATCH 000 of 4] Introduction Peter Zijlstra
2006-10-11 8:52 ` Ingo Molnar [this message]
2006-10-11 9:20 ` Neil Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061011085255.GA6051@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox