From: Mingming Cao <cmm@us.ibm.com>
To: Eric Sandeen <sandeen@redhat.com>, alex@clusterfs.com
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH V2] fix mballoc oopses on mkdir
Date: Wed, 29 Aug 2007 14:01:47 -0700 [thread overview]
Message-ID: <1188421307.3799.32.camel@localhost.localdomain> (raw)
In-Reply-To: <46D3B1AE.40408@redhat.com>
On Tue, 2007-08-28 at 00:25 -0500, Eric Sandeen wrote:
> Ugh. brain clearly not fully engaged... here we go:
>
> ------------------
>
> Tried out Ted's git tree + all pending patches today, and
> immediately oopsed on a mkdir thanks to this in
> ext4_mb_new_group_pa()
>
> BUG_ON(!S_ISREG(ac->ac_inode->i_mode));
>
> (there are 54 BUGs and BUG_ONs in this file...!)
>
> I think something like this patch is needed?
>
Thanks for catching this and the fix. I saw the same kernel oops today
when rum mballoc on fsstress (mkdir). I just added this fix to the patch
queue with some comments.
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>
>
> Index: ext4.git/fs/ext4/extents.c
> ===================================================================
> --- ext4.git.orig/fs/ext4/extents.c
> +++ ext4.git/fs/ext4/extents.c
> @@ -2535,7 +2535,10 @@ int ext4_ext_get_blocks(handle_t *handle
> ar.goal = ext4_ext_find_goal(inode, path, iblock);
> ar.logical = iblock;
> ar.len = allocated;
> - ar.flags = EXT4_MB_HINT_DATA;
> + if (S_ISREG(inode->i_mode))
> + ar.flags = EXT4_MB_HINT_DATA;
> + else
> + ar.flags = 0;
I see. We set the flags to zero here to avoid doing in-core
preallocation for directory files later.
Well, I am not sure whether it's worth the effort to support in-core
preallocation for directory files. But I don't see hard reason we cannot
do this. My understanding is: this is the new in-core preallocation
which does a should not depend on extents or any on-disk format changes.
Alex, any comments?
Mingming
> newblock = ext4_mb_new_blocks(handle, &ar, &err);
> if (!newblock)
> goto out2;
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next parent reply other threads:[~2007-08-29 21:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <46D39776.2090103@redhat.com>
[not found] ` <46D3A390.5000202@redhat.com>
[not found] ` <46D3B1AE.40408@redhat.com>
2007-08-29 21:01 ` Mingming Cao [this message]
[not found] ` <20070828194628.GV5377@schatzie.adilger.int>
[not found] ` <46D48592.4030704@redhat.com>
2007-08-30 14:31 ` [PATCH V2] fix mballoc oopses on mkdir Andreas Dilger
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=1188421307.3799.32.camel@localhost.localdomain \
--to=cmm@us.ibm.com \
--cc=alex@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/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