From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Theodore Tso <tytso@MIT.EDU>
Cc: cmm@us.ibm.com, sandeen@redhat.com, linux-ext4@vger.kernel.org
Subject: Re: [PATCH -V4] ext4: Fix lockdep recursive locking warning
Date: Sun, 23 Nov 2008 22:03:49 +0530 [thread overview]
Message-ID: <20081123163349.GB17002@skywalker> (raw)
In-Reply-To: <20081123024911.GG9150@mit.edu>
On Sat, Nov 22, 2008 at 09:49:11PM -0500, Theodore Tso wrote:
> On Sat, Nov 22, 2008 at 03:46:25PM -0500, Theodore Tso wrote:
> > On Fri, Nov 21, 2008 at 10:10:46PM +0530, Aneesh Kumar K.V wrote:
> > > Indicate that the group locks can be taken in loop.
> >
> > I've been looking at this patch more closely, and I think there's a
> > major problem here.
>
> OK, after looking at this in yet more detail (and having changed
> planes in Dallas :-), I am more than ever convinced this patch is not
> rightq. We have an rw_sem for each block group, grp->alloc_sem, which
> is allocated in groups of meta blockgroups. The whole reason why we
> should worry about keeping them in the same class is we should worry
> about is if for some reason, the multiblock allocator happens to
> allocate two block group's alloc_sem, but one does them out of order
> (say, bg 4, then bg 2, while another does bg 2, then 4), we would get
> a dead lock.
>
> I'm guessing that what caused the problem for you was
> ext4_mb_init_group(), which if you are using 1k filesystems, tries to
> grab multiple grp->alloc_sem's. In each place where we find those, we
> need to use down_write_nested --- see Documentation/lockdep-design.txt.
Correct
>
> If there are any other places in mballoc.c which grabs multiple
> alloc_sem's at the same time, we'll have to use define new subclasses.
No. That is the only call site.
How about the below patch. We can have more than 2 groups in a page
depending on the page size and blocksize. So instead of using
single_depth I guess we should use the relative group number ?.
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 1fa311c..891ce41 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -1783,7 +1783,7 @@ static int ext4_mb_init_group(struct super_block *sb, ext4_group_t group)
* no block allocation going on in any
* of that groups
*/
- down_write(&grp->alloc_sem);
+ down_write_nested(&grp->alloc_sem, i);
}
/*
* make sure we look at only those groups
next prev parent reply other threads:[~2008-11-23 16:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-21 16:40 [PATCH -V4] ext4: Fix lockdep recursive locking warning Aneesh Kumar K.V
2008-11-21 16:48 ` patchqueue update Aneesh Kumar K.V
2008-11-22 20:46 ` [PATCH -V4] ext4: Fix lockdep recursive locking warning Theodore Tso
2008-11-23 2:49 ` Theodore Tso
2008-11-23 16:33 ` Aneesh Kumar K.V [this message]
2008-11-23 18:32 ` Theodore Tso
2008-11-24 5:02 ` Theodore Tso
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=20081123163349.GB17002@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@MIT.EDU \
/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;
as well as URLs for NNTP newsgroup(s).