From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Kevin Shanahan <kmshanah@ucwb.org.au>, linux-ext4@vger.kernel.org
Subject: Re: More ext4 acl/xattr corruption - 4th occurence now
Date: Fri, 15 May 2009 10:28:27 +0530 [thread overview]
Message-ID: <20090515045827.GB1279@skywalker> (raw)
In-Reply-To: <20090514044011.GC11352@mit.edu>
On Thu, May 14, 2009 at 12:40:11AM -0400, Theodore Tso wrote:
> On Wed, May 13, 2009 at 03:56:34PM +0930, Kevin Shanahan wrote:
> >
> > Now, this is (possibly) interesting - that block contains a bunch of
> > file data. Looks like a html email (I can tell it's email because of
> > the FIXED_ prefix added to the tags by the mail sanitizer).
>
> That is interesting. Knowing that it is file data means we might be
> able to track things down this way.
>
> Are you able to apply the following patch to your kernel? If so,
> hopefully we'll be able to catch whatever is causing the problem in
> the act.
>
> - Ted
>
> commit 8ff799da106e9fc4da9b2a3753b5b86caab27f13
> Author: Theodore Ts'o <tytso@mit.edu>
> Date: Thu May 14 00:39:48 2009 -0400
>
> ext4: Add a block validity check to ext4_get_blocks_wrap()
>
> A few users with very large disks have been reporting low block number
> filesystem corruptions, potentially zapping the block group
> descriptors or inodes in the first inode table block. It's not clear
> what is causing this, but most recently, it appears that whatever is
> trashing the filesystem metadata appears to be file data. So let's
> try to set a trap for the corruption in ext4_get_blocks_wrap(), which
> is where logical blocks in an inode are mapped to physical blocks.
We already do block validation in allocator. In
ext4_mb_mark_diskspace_used we check whether the block allocator is
wrongly getting blocks from system zone. So i guess we don't need this
patch. Or may be we need to remove the check in
ext4_mb_mark_diskspace_used and add the ckeck in get_block so that it
catches the extent cache corruption as found by this bug.
-aneesh
>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 4e7f363..4fad4fa 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -1120,6 +1120,35 @@ static void ext4_da_update_reserve_space(struct inode *inode, int used)
> ext4_discard_preallocations(inode);
> }
>
> +static int check_block_validity(struct inode *inode, sector_t logical,
> + sector_t phys, int len)
> +{
> + ext4_fsblk_t valid_block, itable_block;
> + struct ext4_super_block *es = EXT4_SB(inode->i_sb)->s_es;
> + struct ext4_group_desc *gdp = ext4_get_group_desc(inode->i_sb, 0, 0);
> + unsigned int itable_len = EXT4_SB(inode->i_sb)->s_itb_per_group;
> +
> + valid_block = le32_to_cpu(es->s_first_data_block) +
> + EXT4_SB(inode->i_sb)->s_gdb_count;
> + itable_block = ext4_inode_table(inode->i_sb, gdp);
> +
> + if (unlikely((phys <= valid_block) ||
> + ((phys + len - 1) > ext4_blocks_count(es)) ||
> + ((phys >= itable_block) &&
> + (phys <= itable_block + itable_len)) ||
> + ((phys + len - 1 >= itable_block) &&
> + (phys + len - 1 <= itable_block + itable_len)))) {
> + ext4_error(inode->i_sb, "check_block_validity",
> + "inode #%lu logical block %llu mapped to %llu "
> + "(size %d)", inode->i_ino,
> + (unsigned long long) logical,
> + (unsigned long long) phys, len);
> + WARN_ON(1);
> + return -EIO;
> + }
> + return 0;
> +}
> +
> /*
> * The ext4_get_blocks_wrap() function try to look up the requested blocks,
> * and returns if the blocks are already mapped.
> @@ -1165,6 +1194,13 @@ int ext4_get_blocks_wrap(handle_t *handle, struct inode *inode, sector_t block,
> }
> up_read((&EXT4_I(inode)->i_data_sem));
>
> + if (retval > 0 && buffer_mapped(bh)) {
> + int ret = check_block_validity(inode, block,
> + bh->b_blocknr, retval);
> + if (ret != 0)
> + return ret;
> + }
> +
> /* If it is only a block(s) look up */
> if (!create)
> return retval;
> @@ -1241,6 +1277,12 @@ int ext4_get_blocks_wrap(handle_t *handle, struct inode *inode, sector_t block,
> }
>
> up_write((&EXT4_I(inode)->i_data_sem));
> + if (retval > 0 && buffer_mapped(bh)) {
> + int ret = check_block_validity(inode, block,
> + bh->b_blocknr, retval);
> + if (ret != 0)
> + return ret;
> + }
> return retval;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-05-15 4:58 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-13 6:26 More ext4 acl/xattr corruption - 4th occurence now Kevin Shanahan
2009-05-13 23:56 ` Kevin Shanahan
2009-05-14 4:40 ` Theodore Tso
2009-05-14 11:07 ` Kevin Shanahan
2009-05-14 11:17 ` Manish Katiyar
2009-05-14 12:30 ` Theodore Tso
2009-05-14 13:25 ` Kevin Shanahan
2009-05-14 14:07 ` Theodore Tso
2009-05-14 14:30 ` Kevin Shanahan
2009-05-14 15:44 ` Eric Sandeen
2009-05-14 21:07 ` Kevin Shanahan
2009-05-14 21:08 ` Eric Sandeen
2009-05-14 16:12 ` Theodore Tso
2009-05-14 21:02 ` Kevin Shanahan
2009-05-14 21:23 ` Theodore Tso
2009-05-14 21:33 ` Kevin Shanahan
2009-05-15 23:18 ` Kevin Shanahan
2009-05-15 1:21 ` Eric Sandeen
2009-05-15 12:50 ` Theodore Tso
2009-05-15 12:58 ` Eric Sandeen
2009-05-15 15:24 ` Eric Sandeen
2009-05-15 16:27 ` Eric Sandeen
2009-05-15 4:55 ` Aneesh Kumar K.V
2009-05-15 10:11 ` Theodore Tso
2009-05-15 13:07 ` Theodore Tso
2009-05-19 10:00 ` Thierry Vignaud
2009-05-19 11:36 ` Theodore Tso
2009-05-19 12:01 ` Alex Tomas
2009-05-19 15:04 ` Theodore Tso
2009-05-19 15:16 ` Alex Tomas
2009-05-19 15:18 ` Thierry Vignaud
2009-05-15 3:57 ` Alex Tomas
2009-05-15 4:58 ` Aneesh Kumar K.V [this message]
2009-05-15 10:27 ` Theodore Tso
2009-05-18 2:14 ` [PATCH] ext4: Add a comprehensive block validity check to ext4_get_blocks() (Was: More ext4 acl/xattr corruption - 4th occurence now) Theodore Tso
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=20090515045827.GB1279@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=kmshanah@ucwb.org.au \
--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 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).