All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manish Katiyar <mkatiyar@gmail.com>
To: Kevin Shanahan <kmshanah@ucwb.org.au>
Cc: Theodore Tso <tytso@mit.edu>, linux-ext4@vger.kernel.org
Subject: Re: More ext4 acl/xattr corruption - 4th occurence now
Date: Thu, 14 May 2009 16:47:14 +0530	[thread overview]
Message-ID: <ea11fea30905140417i53c252cbra7c8041021d425e1@mail.gmail.com> (raw)
In-Reply-To: <20090514110659.GA5146@kulgan>

On Thu, May 14, 2009 at 4:37 PM, Kevin Shanahan <kmshanah@ucwb.org.au> wrote:
> 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?

Hi Ted,

If we have the possibility of applying patches why not apply this too
and try http://markmail.org/message/e3uwzxrd42isxczg . After all it
originated from this bug only.

Thanks -
Manish


>> If so,
>> hopefully we'll be able to catch whatever is causing the problem in
>> the act.
>
> Sure - now running with 2.6.29.3 + your patch.
>
>  patching file fs/ext4/inode.c
>  Hunk #1 succeeded at 1040 with fuzz 1 (offset -80 lines).
>  Hunk #2 succeeded at 1113 (offset -81 lines).
>  Hunk #3 succeeded at 1184 (offset -93 lines).
>
> I'll report any hits for "check_block_validity" in syslog.
>
> Thankyou, much appreciated.
>
> Cheers,
> Kevin.
>
>> 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.
>>
>>     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
>



-- 
Thanks -
Manish
--
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

  reply	other threads:[~2009-05-14 11:17 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 [this message]
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
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=ea11fea30905140417i53c252cbra7c8041021d425e1@mail.gmail.com \
    --to=mkatiyar@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.