linux-ext4 - Re: [PATCH] e2fsprogs: allocate inode table wholly within group

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <524AE9A5.4010309@redhat.com>
Date:	Tue, 01 Oct 2013 10:26:29 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>
CC:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] e2fsprogs: allocate inode table wholly within group

On 9/30/13 8:57 PM, Theodore Ts'o wrote:
> On Mon, Jul 08, 2013 at 04:27:21PM -0500, Eric Sandeen wrote:
>>
>> The actual problem seems to be that the test does successive "-M" minimal resizes, and eventually we resize into the middle of an inode table, leaving the end of the table beyond the fs.
>>
>> Point "resize2fs -M" at the attached image once or twice w/ fscks in between and you should see it.
> 
> I've been going through my patch backlog, so I finally had a chance to
> take a very close look at your test image.  I now understand why
> things are failing.
> 
> 1) The test image (which you said was generated on a ppc e2fsprogs?)
> was doing something very weird as far as the location of the
> allocation bitmaps and inode table:

Yes, this was just during a fedora build, during the "make check" phase.

https://bugzilla.redhat.com/show_bug.cgi?id=980519

No idea why things should be coming out differently, that's a bit
alarming in and of itself.

(Fedora isn't carrying any interesting patches to speak of).

-Eric

> Filesystem features:      ext_attr dir_index filetype sparse_super
> Inode count:              512
> Block count:              1247
>    ...
> 
> Group 0: (Blocks 1-1024)
>   Primary superblock at 1, Group descriptors at 2-2
>   Block bitmap at 66 (+65), Inode bitmap at 67 (+66)
>   Inode table at 68-99 (+67)
> 
> Group 1: (Blocks 1025-1246)
>   Backup superblock at 1025, Group descriptors at 1026-1026
>   Block bitmap at 1090 (+65), Inode bitmap at 1091 (+66)
>   Inode table at 1092-1123 (+67)
> 
> Compare and contrast this with what x86 and Debian's ppc mke2fs creates:
> 
> Group 0: (Blocks 1-1024)
>   Primary superblock at 1, Group descriptors at 2-2
>   Block bitmap at 3 (+2), Inode bitmap at 4 (+3)
>   Inode table at 5-14 (+4)
> 
> Group 1: (Blocks 1025-1246)
>   Backup superblock at 1025, Group descriptors at 1026-1026
>   Block bitmap at 1027 (+2), Inode bitmap at 1028 (+3)
>   Inode table at 1029-1038 (+4)
> 
> So I'm not sure why Fedora's ppc mke2fs is creating file systems in
> this way, but that's one of the causes of the bug.
> 
> 
> 2) The second cause of the bug is that
> calculate_minimum_resize_size(), when we calculate the number of
> blocks for the last group, the code has an implicit assumption that
> the metadata blocks are located at the very beginning of the block
> group.   That's an easy fix.
> 
>> It seems like the obvious fix would be to move the inode table if
>> necessary, as with the following patch.
> 
> Your patch is a good one, but at least in the context of resize2fs -M,
> we should be fixing calculate_minimum_resize_size() so we can avoid
> needing to move the inode table (since even if it can succeed, it's
> not worth the danger).
> 
> I'll send out some patches to address this.  Thanks for sending the
> test image; and my apologies for not having time to get back to this
> until now.
> 
> 					- Ted
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html