From: Mingming Cao <cmm@us.ibm.com>
To: Dave Kleikamp <shaggy@austin.ibm.com>
Cc: Badari Pulavarty <pbadari@us.ibm.com>,
Badari Pulavarty <pbadari@gmail.com>,
Will Simoneau <simoneau@ele.uri.edu>,
lkml <linux-kernel@vger.kernel.org>,
ext4 <linux-ext4@vger.kernel.org>
Subject: Re: BUG: warning at fs/ext3/inode.c:1016/ext3_getblk()
Date: Tue, 05 Sep 2006 14:51:41 -0700 [thread overview]
Message-ID: <44FDF16D.8040505@us.ibm.com> (raw)
In-Reply-To: <1157491179.19432.11.camel@kleikamp.austin.ibm.com>
Dave Kleikamp wrote:
> On Tue, 2006-09-05 at 13:14 -0700, Badari Pulavarty wrote:
>
>>Dave Kleikamp wrote:
>
>
>>>I'm having a hard time figuring out exactly what ext3_get_blocks_handle
>>>is trying to return, but it looks to me like if it is allocating one
>>>data block, and needs to allocate an indirect block as well, then it
>>>will return 2 rather than 1. Is this expected, or am I just confused?
>>>
>>>
>>
>>It would return "1" in that case.. (data block)
>>
>> > 0 means get_block() suceeded and indicates the number of blocks mapped
>>= 0 lookup failed
>>< 0 mean error case
>
>
> Okay, I got confused looking through the code. I still don't see how
> ext3_get_blocks_handle() should be returning a number greater than
> maxblocks.
>
yes ext3_get_blocks_handle() will return the number of data blocks
allocated(not including the indirect/double indirecto blocks), and that
number should not than maxblocks. In this case, it should return 1 instead.
The ext3_get_blocks_handle() behavior was changed when multiple blocks
map/allocation was added to ext3 via this function. Previously, the
behavior of ext3_get_blokc_handle() returns 0 for success case, and
returns non-zero(nagive) for error case. While with new behavior, the
success case is the thre returned value should > 0.
How many blocks is being mapped in this case? > 1? or 0? If it failed to
map the block (ext3_get_blocks_handle() returns 0), ext3_getblk() will
also WARN_ON().
>
>>>>I did search for callers of ext3_get_blocks_handle() and found that
>>>>ext3_readdir() seems to do wrong thing all the time with error check :(
>>>>Need to take a closer look..
>>>>
>>>> err = ext3_get_blocks_handle(NULL, inode, blk, 1,
>>>> &map_bh, 0, 0);
>>>> if (err > 0) { <<<< BAD
>>>> page_cache_readahead(sb->s_bdev->bd_inode->i_mapping,
>>>> &filp->f_ra,
>>>> filp,
>>>> map_bh.b_blocknr >>
>>>> (PAGE_CACHE_SHIFT - inode->i_blkbits),
>>>> 1);
>>>> bh = ext3_bread(NULL, inode, blk, 0, &err);
>>>> }
>>>>
>>>
>>>Bad to do what it's doing, or bad to call name the variable "err"?
>>>I think if it looked like this:
>>>
>>> count = ext3_get_blocks_handle(NULL, inode, blk, 1,
>>> &map_bh, 0, 0);
>>> if (count > 0) {
>>>
>>>it would be a lot less confusing.
>>>
>>
>>I am sorry !! it is doing the right thing :(
>
>
> Not your fault. The variable is very badly named.
next prev parent reply other threads:[~2006-09-05 21:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-05 17:10 BUG: warning at fs/ext3/inode.c:1016/ext3_getblk() Will Simoneau
2006-09-05 18:09 ` Badari Pulavarty
2006-09-05 18:57 ` Dave Kleikamp
2006-09-05 20:14 ` Badari Pulavarty
2006-09-05 21:19 ` Dave Kleikamp
2006-09-05 21:51 ` Mingming Cao [this message]
2006-09-05 21:06 ` Badari Pulavarty
2006-09-05 21:47 ` Will Simoneau
2006-09-05 22:43 ` Badari Pulavarty
2006-09-05 23:19 ` Mingming Cao
2006-09-06 1:53 ` Will Simoneau
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=44FDF16D.8040505@us.ibm.com \
--to=cmm@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbadari@gmail.com \
--cc=pbadari@us.ibm.com \
--cc=shaggy@austin.ibm.com \
--cc=simoneau@ele.uri.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.