All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: BUG: unable to handle kernel NULL pointer dereference at 00000000 [ext4_new_meta_blocks+0x7c/0xb7]
Date: Wed, 17 Dec 2008 13:26:35 +0530	[thread overview]
Message-ID: <20081217075635.GA7685@skywalker> (raw)
In-Reply-To: <20081212145609.GA26085@mit.edu>

On Fri, Dec 12, 2008 at 09:56:09AM -0500, Theodore Tso wrote:
> On Tue, Dec 09, 2008 at 04:11:22PM +0530, Aneesh Kumar K.V wrote:
> > The problem is due to remove-do_blk_alloc patch.
> > 
> > The patch below should fix the crash. 
> > 
> > -		EXT4_I(inode)->i_allocated_meta_blocks += *count;
> > +		EXT4_I(inode)->i_allocated_meta_blocks += ar.len;
> 
> 
> Good catch, thanks.  I'll add it to the patch queue.
> 
> > I have one question regarding the patch. What about blocks allocated for
> > directories for the  ext3 format.  With extent format we are not
> > setting EXT4_MB_HINT_DATA for non regular files. So i guess we also
> > need the below patch .
> 
> One of the good things about getting rid of too many layers of
> abstractions is that it makes bugs like this easier to spot.  We've
> been sending allocating directory and symlinks using EXT4_MB_HINT_DATA
> if extents haven't been enabled, and no one noticed before we
> simplified out things....

We had always sent the directory allocation request with
EXT4_MB_HINT_DATA not set.  With Linus kernel I have this

671 static ext4_fsblk_t do_blk_alloc(handle_t *handle, struct inode *inode,
.....
....
686         if (S_ISREG(inode->i_mode) && !(flags & EXT4_META_BLOCK))
687                 /* enable in-core preallocation for data block allocation */
688                 ar.flags = EXT4_MB_HINT_DATA;
689         else
690                 /* disable in-core preallocation for non-regular files */
691                 ar.flags = 0;


That means if the request for block allocation is not on regular files
set ar.flags = 0; For regular files if the request is for meta-data
blocks set ar.glags = 0.



> 
> Actually, I wonder if maybe we should set EXT4_MB_HINT_DATA for
> directories as well.  Making directories contiguous does speed up
> certain workloads, and it does speed up fsck.  It may be though that
> the mballoc algorithms should be tuned specifically for directories,
> and what we should do is to define a new flag, EXT4_MB_HINT_DIRECTORY,
> and pass it in for that case. 
> 
> Some experimentation is clearly called for, here....
> 

True. But with the changes to do do_blk_alloc I guess we need to make
sure we request directories with EXT4_MB_HINT_DATA not set.

-aneesh

  reply	other threads:[~2008-12-17  8:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-09 10:41 BUG: unable to handle kernel NULL pointer dereference at 00000000 [ext4_new_meta_blocks+0x7c/0xb7] Aneesh Kumar K.V
2008-12-12 14:56 ` Theodore Tso
2008-12-17  7:56   ` Aneesh Kumar K.V [this message]
2008-12-17 11:47     ` Theodore Tso
2008-12-17 16:25       ` Aneesh Kumar K.V
2008-12-18  8:55       ` Andreas Dilger
2009-01-02  5:08 ` 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=20081217075635.GA7685@skywalker \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --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 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.