public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
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

       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