From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: cmm@us.ibm.com, sandeen@redhat.com, linux-ext4@vger.kernel.org
Subject: Re: [PATCH -V2 1/4] ext4: Check for only delay or unwritten buffer_heads
Date: Thu, 4 Jun 2009 09:16:44 -0400 [thread overview]
Message-ID: <20090604131644.GG21314@mit.edu> (raw)
In-Reply-To: <1244095805-17015-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
I've added this patch to the ext4 patch queue with the folloiwng
changelog comment:
ext4: Fix mmap/truncate race when blocksize < pagesize && delayed allocation
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
It is possible to see buffer_heads which are not mapped in the
writepage callback in the following scneario (where the fs blocksize
is 1k and the page size is 4k):
1) truncate(f, 1024)
2) mmap(f, 0, 4096)
3) a[0] = 'a'
4) truncate(f, 4096)
5) writepage(...)
Now if we get a writepage callback immediately after (4) and before an
attempt to write at any other offset via mmap address (which implies we
are yet to get a pagefault and do a get_block) what we would have is the
page which is dirty have first block allocated and the other three
buffer_heads unmapped.
In the above case the writepage should go ahead and try to write the
first blocks and clear the page_dirty flag. Further attempts to write
to the page will again create a fault and result in allocating blocks
and marking page dirty. If we don't write any other offset via mmap
address we would still have written the first block to the disk and
rest of the space will be considered as a hole.
So to address this, we change all of the places where we look for
delayed, unmapped, or unwritten buffer heads, and only check for
delayed or unwritten buffer heads instead.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
- Ted
prev parent reply other threads:[~2009-06-04 13:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-04 6:10 [PATCH -V2 1/4] ext4: Check for only delay or unwritten buffer_heads Aneesh Kumar K.V
2009-06-04 6:10 ` [PATCH -V2 2/4] ext4: Add generic writepage callback Aneesh Kumar K.V
2009-06-04 6:10 ` [PATCH -V2 3/4] ext4: Move some static functions around Aneesh Kumar K.V
2009-06-04 6:10 ` [PATCH -V2 4/4] ext4: Add WARN_ON on unmapped dirty buffer_heads in writepage Aneesh Kumar K.V
2009-06-04 13:50 ` Theodore Tso
2009-06-04 13:47 ` [PATCH -V2 3/4] ext4: Move some static functions around Theodore Tso
2009-06-04 12:05 ` [PATCH -V2 2/4] ext4: Add generic writepage callback Theodore Tso
2009-06-04 13:20 ` Theodore Tso
2009-06-04 13:16 ` Theodore Tso [this message]
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=20090604131644.GG21314@mit.edu \
--to=tytso@mit.edu \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.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).