linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vegard Nossum <vegard.nossum@oracle.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH] ext4: validate number of meta clusters in group
Date: Mon, 11 Jul 2016 22:30:21 +0200	[thread overview]
Message-ID: <578401DD.1050601@oracle.com> (raw)
In-Reply-To: <5783EA91.30402@oracle.com>

On 07/11/2016 08:50 PM, Vegard Nossum wrote:
> On 07/11/2016 04:51 AM, Theodore Ts'o wrote:
>> On Thu, Jul 07, 2016 at 10:10:40PM +0200, Vegard Nossum wrote:
>>>
>>> I ran into a second problem (this time it was num_clusters_in_group()
>>> returning a bogus value) with the same symptoms (random memory
>>> corruptions), the new attached patch fixes both problems by checking the
>>> values at mount time.
>>
>> Can you give me a dumpe2fs -h of a file system that is causing
>> num_clusters_in_group() to be bogus?
>>
>> I want to make sure I'm checking that correct base values, insteda of
>> doing a brute force loop over all of the block groups and calling
>> ext4_num_clusters_in_group() and ext4_num_base_meta_clusters() for all
>> block groups.
>>
>> Thanks!!
>
> It's sbi->s_es->s_reserved_gdt_blocks:

Durrr, no, it's not, I just realised you asked about
num_clusters_in_group() and not num_base_meta_clusters().

So I did the same thing for that and I tracked it down to
s_blocks_count_{lo,hi} both being 0, causing num_clusters_in_group() to
effectively return 0 - ext4_group_first_block_no(sb, block_group).

But dumpe2fs shows block count to be 16384, so I was a bit puzzled. I
set a breakpoint on s_blocks_count_lo and indeed it's being corrupted:

Hardware watchpoint 2: ((struct ext4_super_block *) 
0x61e2c400)->s_blocks_count_lo

Old value = 16384
New value = 0
0x00000000602d9d59 in memset ()
(gdb) bt
#0  0x00000000602d9d59 in memset ()
#1  0x000000006010e944 in ext4_init_block_bitmap (...) at 
fs/ext4/balloc.c:215
#2  ext4_read_block_bitmap_nowait (...) at fs/ext4/balloc.c:455

Curiously enough, that's this memset() in the same function:

         memset(bh->b_data, 0, sb->s_blocksize);

Checking with some debug printks, it indeed seems like bh->b_data points
to the struct ext4_super_block (!):

  &EXT4_SB(sb)->s_es->s_blocks_count_lo = 0000000063a3c404
  bh->b_data = 0000000063a3c400
  bh->b_size = 400

Well, you can disregard my patch for sure. I'm not sure how the bitmap
we're supposed to initialise ends up pointing to the ext4_super_block
though.


Vegard

      reply	other threads:[~2016-07-11 20:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-01 13:06 [RFC PATCH] ext4: validate number of meta clusters in group Vegard Nossum
2016-07-02  7:49 ` Darrick J. Wong
2016-07-06  0:03   ` [PATCH] ext4: validate s_reserved_gdt_blocks on mount Theodore Ts'o
2016-07-07 20:10   ` [RFC PATCH] ext4: validate number of meta clusters in group Vegard Nossum
2016-07-11  2:51     ` Theodore Ts'o
2016-07-11 18:50       ` Vegard Nossum
2016-07-11 20:30         ` Vegard Nossum [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=578401DD.1050601@oracle.com \
    --to=vegard.nossum@oracle.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@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).