All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Mingming Cao <cmm@us.ibm.com>
Cc: tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: When reading from fallocated blocks make sure we return zero.
Date: Sat, 16 Feb 2008 08:53:34 +0530	[thread overview]
Message-ID: <20080216032334.GA6501@skywalker> (raw)
In-Reply-To: <1203104584.3598.4.camel@localhost.localdomain>

On Fri, Feb 15, 2008 at 11:43:04AM -0800, Mingming Cao wrote:
> On Fri, 2008-02-15 at 23:46 +0530, Aneesh Kumar K.V wrote:
> > fallocate blocks are considered as sparse area and read from them should
> > return zero. ext4_ext_get_blocks should return zero for read request.
> > 
> 
> The patch itself looks harmless, but I still don't see how this could
> fix the problem you described at irc: a write hit a BUG_ON() in
> fs/buffer.c saying the buffer is not mapped. Could you add more details
> here?

Write will take the below call chain

ext4_write_begin
  block_write_begin
    __block_prepare_write
       ext4_getblock
         ext4_get_blocks_wrap
(1)	   ext4_ext_get_blocks with create = 0 return allocated
       ll_rw_block  if buffer not uptodate.
         submit_bh
	   BUG_ON(!buffer_mapped(bh))


ext4_ext_get_blocks at (1) should have returned 0. That would cause
ext4_get_blocks_wrap to again call ext4_ext_get_blocks with create = 1
and that would have returned us the buffer head which is mapped. This
would also result in splitting the extent to initialized and
uninitialized one.


-aneesh

  reply	other threads:[~2008-02-16  3:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-15 18:16 [PATCH] ext4: When reading from fallocated blocks make sure we return zero Aneesh Kumar K.V
2008-02-15 19:43 ` Mingming Cao
2008-02-16  3:23   ` Aneesh Kumar K.V [this message]
2008-02-18  7:45     ` Aneesh Kumar K.V
2008-02-19  0:14     ` Mingming Cao
2008-02-19  3:19       ` Aneesh Kumar K.V
2008-02-19  5:24         ` Mingming Cao

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=20080216032334.GA6501@skywalker \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cmm@us.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.