From: "Darrick J. Wong" <djwong@us.ibm.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: [PATCH] ext4: Always verify extent tree blocks
Date: Thu, 11 Aug 2011 14:13:41 -0700 [thread overview]
Message-ID: <20110811211348.GK20655@tux1.beaverton.ibm.com> (raw)
It turns out that ext4_ext_check only verifies the validity of the extent block
it's processing if the block has to be read in from the disk. Unfortunately,
this means that the check is NOT done if the block is already in memory, which
means that if a file has a corrupted extent block, then the first IO peformed
on the file will find the corrupt block and fail, but a second IO will see that
the extent block is in memory, bypass the corruption check, and use garbage
data as if they were extent data.
A simple testcase is to allocate a file with enough extents to overflow the
inode i_block, umount, overwrite the extent block magic with garbage, then
mount the filesystem and try to access the file. The first access causes the
kernel to spit out an error, but subsequent accesses seem to succeed.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
---
fs/ext4/extents.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ee4b391..bb07b79 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -744,8 +744,6 @@ ext4_ext_find_extent(struct inode *inode, ext4_lblk_t block,
i = depth;
/* walk through the tree */
while (i) {
- int need_to_validate = 0;
next reply other threads:[~2011-08-11 21:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-11 21:13 Darrick J. Wong [this message]
2011-08-11 21:33 ` [PATCH] ext4: Always verify extent tree blocks Andreas Dilger
2011-08-11 22:14 ` Darrick J. Wong
2011-08-11 22:30 ` Andreas Dilger
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=20110811211348.GK20655@tux1.beaverton.ibm.com \
--to=djwong@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox