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 21:55:54 +0530 [thread overview]
Message-ID: <20081217162554.GA6863@skywalker> (raw)
In-Reply-To: <20081217114711.GL10590@mit.edu>
On Wed, Dec 17, 2008 at 06:47:11AM -0500, Theodore Tso wrote:
> On Wed, Dec 17, 2008 at 01:26:35PM +0530, Aneesh Kumar K.V wrote:
> > > 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 extents, yes. With normal indirect block-based files, no. I
> agree that for consistency's sake, it should be the same, but at the
> moment, it isn't.
Hmm. May be I am missing something. This is the call chain i followed
with the Linus tree.
ext4_get_block
ext4_get_blocks_wrap
ext4_get_blocks_handle
ext4_alloc_branch
ext4_alloc_blocks
ext4_new_meta_blocks
do_blk_alloc -> which set ar.flags = 0 for meta data.
ext4_new_blocks
do_blk_alloc -> which set ar.flags = 0 for !S_ISREG(inode->i_mode)
So the current Linus kernel using mballoc for non extent format doesn't
set EXT4_MB_HINT_DATA for directories.
-aneesh
next prev parent reply other threads:[~2008-12-17 16:30 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
2008-12-17 11:47 ` Theodore Tso
2008-12-17 16:25 ` Aneesh Kumar K.V [this message]
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=20081217162554.GA6863@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.