All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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.