From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: NeilBrown <neilb@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [PATCH 000 of 4] Introduction
Date: Wed, 11 Oct 2006 10:44:36 +0200 [thread overview]
Message-ID: <1160556276.2006.27.camel@taijtu> (raw)
In-Reply-To: <20061011155522.7915.patches@notabene>
On Wed, 2006-10-11 at 16:09 +1000, NeilBrown 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.
>
> The core issue is that blkdev_get when called on a partition needs to
> lock (bd_mutex) the partition and the whole device. lockdep would
> normally see this as a possible deadlock and needs to be told that
> this particular nesting is known to be safe.
>
> The code to do this is in -linus is rather messy, largely because the
> locking itself is messy. The bd_mutex for the whole is taken several
> times while bd_mutex for the partition is held, and it is taken at
> both levels of the recursion (blkdev_get calls blkdev_get - only to
> one level).
>
> As key observation to simplifying the locking is to observer that a
> lot of the locking is there to protect the updating of bd_part_count.
> If those updates are moved, the locking can become simpler.
>
> The first patch removes the current approach in -mm to handling this
> nesting and explains why it is not ideal.
> This reverts new-bd_mutex-lockdep-annotation.patch
>
> The second simplifies the locking as explained above.
>
> The third adds the mutex_lock_nested annotations, which are now trivial.
>
> 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.
>
> [PATCH 000 of 4] Introduction
> [PATCH 001 of 4] Remove lock_key approach to managing nested bd_mutex locks.
> [PATCH 002 of 4] Simplify some aspects of bd_mutex nesting.
> [PATCH 003 of 4] Use mutex_lock_nested for bd_mutex to avoid lockdep warning.
> [PATCH 004 of 4] Avoid lockdep warning in md.
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
next prev parent reply other threads:[~2006-10-11 8:44 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 ` Peter Zijlstra [this message]
2006-10-11 8:52 ` [PATCH 000 of 4] Introduction Ingo Molnar
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=1160556276.2006.27.camel@taijtu \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.