linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Allison Henderson <achender@linux.vnet.ibm.com>
To: Yongqiang Yang <xiaoqiangnk@gmail.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: question about punch hole
Date: Fri, 26 Aug 2011 15:35:31 -0700	[thread overview]
Message-ID: <4E581FB3.3020504@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAGBYx2abeJQBuZDV11WtrprmareZWSNkv-HGdLMvYoMB36mqZA@mail.gmail.com>

On 08/25/2011 07:53 PM, Yongqiang Yang wrote:
> Hi Allison,
>
> Currently, punch hole flushes all pages to disk and releases pages in
> page cache, and then calls ext4_ext_map_blocks.
>
> Assume that if a new page in the punching's range is mapped after
> releasing pages and before down_write i_data_sem,
> then ext4_ext_map_blocks will release map info of the page in extent
> tree.  However, up layers does not know this, and they think the page
> is mapped.
>
> I can not find how punch hole handle the situation above.  Could you
> shed a light on it?
>
>
Hi Yongqiang

This is a really good question and at the moment Im still looking into 
it.  :)  The calling sequence in punch hole was modeled after truncate, 
which also only locks i_data_sem when modifying the extent tree. 
ext4_ext_map_blocks when called with the punch hole flag, only releases 
blocks in the extent tree, using the same routines truncate does, but it 
does not modify the state of the pages. Though that still does not 
prevent the race condition you describe, so I am still investigating it.
I've found that I can catch a lot of race conditions by simply running 
the stress test over night, and so far I havnt had anything like this 
come up, but that certainly doesnt mean its not there.  I will let you 
know what I find.  Thx!

Allison Henderson

  reply	other threads:[~2011-08-26 22:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-26  2:53 question about punch hole Yongqiang Yang
2011-08-26 22:35 ` Allison Henderson [this message]
2011-08-27  9:04   ` Yongqiang Yang
2011-08-27  9:33     ` Yongqiang Yang
2011-08-28  1:09       ` Allison Henderson

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=4E581FB3.3020504@linux.vnet.ibm.com \
    --to=achender@linux.vnet.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=xiaoqiangnk@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).