From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Valerie Clement <valerie.clement@bull.net>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] fix file system corruption [ was Re: mballoc errors ]
Date: Tue, 1 Apr 2008 14:31:49 +0530 [thread overview]
Message-ID: <20080401090149.GB9121@skywalker> (raw)
In-Reply-To: <47F1F49A.7020102@bull.net>
On Tue, Apr 01, 2008 at 10:38:50AM +0200, Valerie Clement wrote:
>
> Hi Aneesh,
> I tested your patch but unfortunately I still reproduced the problem with it:
> EXT4-fs error (device sdc1): ext4_valid_block_bitmap: Invalid block
> bitmap - block_group = 6233, block = 51060737
>
Below is the patch i am testing. It is running fine for me here. I am
testing the patch with a modified fsstress that use fallocate.
Regarding the test case that you have i am not yet sure what is causing
the file system corruption. It cannot be ext4_ext_zeroout or
ext4_ext_convert_to_initialized because they are used only when we are
writing to falloc area and you are not preallocating anything in your
test. Did you make sure you are not using delalloc ? All my tests are
run with stable branch.
You would also need the single line change you found in ext4_ext_zeroout
It is already a part of patch queue.
commit c664eac338ae9c6139ffec72fca84b222bf142b2
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date: Tue Apr 1 13:23:21 2008 +0530
ext4: Cache the correct extent length for uninit extent.
When we convert uninitialized extent to initialized extent
we need to make sure we return the number of blocks in the
extent from the file system block corresponding to logical
file block. Other wise we cache wrong extent details and this
results in file system corruption.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 964d2c1..30f0f99 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2264,7 +2264,8 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
ex->ee_len = orig_ex.ee_len;
ext4_ext_store_pblock(ex, ext_pblock(&orig_ex));
ext4_ext_dirty(handle, inode, path + depth);
- return le16_to_cpu(ex->ee_len);
+ /* zeroed the full extent */
+ return allocated;
}
/* ex1: ee_block to iblock - 1 : uninitialized */
@@ -2309,11 +2310,44 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
ex->ee_len = orig_ex.ee_len;
ext4_ext_store_pblock(ex, ext_pblock(&orig_ex));
ext4_ext_dirty(handle, inode, path + depth);
- return le16_to_cpu(ex->ee_len);
+ /* zeroed the full extent */
+ return allocated;
} else if (err)
goto fix_extent_len;
+ /* We need to zero out the second half because
+ * fallocate request can update file size and
+ * converting the second half to initialized extent
+ * implies that we can leak some junk data to user
+ * space
+ */
+ err = ext4_ext_zeroout(inode, ex3);
+ if (err) {
+ /*
+ * We should actually mark the
+ * second half as uninit and return error
+ * Insert would have changed the extent
+ */
+ depth = ext_depth(inode);
+ ext4_ext_drop_refs(path);
+ path = ext4_ext_find_extent(inode,
+ iblock, path);
+ if (IS_ERR(path)) {
+ err = PTR_ERR(path);
+ return err;
+ }
+ ex = path[depth].p_ext;
+ err = ext4_ext_get_access(handle, inode,
+ path + depth);
+ if (err)
+ return err;
+ ext4_ext_mark_uninitialized(ex);
+ ext4_ext_dirty(handle, inode, path + depth);
+ return err;
+ }
+
+ /* zeroed the second half */
return allocated;
}
ex3 = &newex;
@@ -2331,7 +2365,8 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
ex->ee_len = orig_ex.ee_len;
ext4_ext_store_pblock(ex, ext_pblock(&orig_ex));
ext4_ext_dirty(handle, inode, path + depth);
- return le16_to_cpu(ex->ee_len);
+ /* zeroed the full extent */
+ return allocated;
} else if (err)
goto fix_extent_len;
@@ -2379,7 +2414,8 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
ex->ee_len = orig_ex.ee_len;
ext4_ext_store_pblock(ex, ext_pblock(&orig_ex));
ext4_ext_dirty(handle, inode, path + depth);
- return le16_to_cpu(ex->ee_len);
+ /* zero out the first half */
+ return allocated;
}
}
/*
@@ -2446,7 +2482,8 @@ insert:
ex->ee_len = orig_ex.ee_len;
ext4_ext_store_pblock(ex, ext_pblock(&orig_ex));
ext4_ext_dirty(handle, inode, path + depth);
- return le16_to_cpu(ex->ee_len);
+ /* zero out the first half */
+ return allocated;
} else if (err)
goto fix_extent_len;
out:
next prev parent reply other threads:[~2008-04-01 9:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-26 21:41 mballoc errors Eric Sandeen
2008-03-26 23:23 ` Bernd Schubert
2008-03-26 23:31 ` Mingming Cao
2008-03-27 3:48 ` Aneesh Kumar K.V
2008-03-27 7:53 ` Solofo.Ramangalahy
2008-03-28 14:03 ` Valerie Clement
[not found] ` <20080331065802.GA19456@skywalker>
[not found] ` <47F0FBFE.7060404@bull.net>
2008-03-31 20:18 ` Aneesh Kumar K.V
2008-03-31 20:50 ` [PATCH] fix file system corruption [ was Re: mballoc errors ] Aneesh Kumar K.V
2008-04-01 8:38 ` Valerie Clement
2008-04-01 9:01 ` Aneesh Kumar K.V [this message]
2008-04-01 9:46 ` Valerie Clement
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=20080401090149.GB9121@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=valerie.clement@bull.net \
/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).