linux-ext4 - Re: Online resize issue with 3.13.5 & 3.15.6

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] [day] [month] [year] [list]

Date:	Tue, 29 Jul 2014 16:00:24 +0800
From:	Brad Campbell <lists2009@...rfbargle.com>
To:	Theodore Ts'o <tytso@....edu>
CC:	Azat Khuzhin <a3at.mail@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: Online resize issue with 3.13.5 & 3.15.6

On 29/07/14 10:46, Theodore Ts'o wrote:
> On Sat, Jul 26, 2014 at 09:46:20PM +0800, Brad Campbell wrote:
>> Fast forward 12 months and
>> I've added 2 drives to the array and bumped up against this issue. So it was
>> initially 4883458240 blocks. It would have been created with e2fsprogs from
>> Debian Stable (so 1.42.5).
>
> Confirmed; debian stable's mke2fs version 1.42.5 does the wrong thing
> if you do:
>
>     mke2fs -t ext4 -O 64bit,resize_inode /mnt/foo.img  19T
>
> It creates a file system which is has a resize_inode which --- well,
> is in a format that the kernel isn't capable of handling and which is
> not something that was originally intended.  The interesting thing is
> that resize2fs 1.42.11 is apparently able to handle resizing the above
> file system created with mke2fs 1.42.5.

And it did just fine once patched for the 32bit overflow. The off-line 
resize went without a hitch. Oddly enough the Kernel took it out to 
5641863168 blocks ok in the first online attempt.

> Mke2fs 1.42.12 will avoid creating a resize_inode for file systems >
> 16T, so this situation doesn't arise.
>
> I need to take a closer look to see if there's some way I can teach
> the kernel to be able to deal with this file system, but for now, you
> can work around it by using tune2fs to remove the resize_inode, and
> after running e2fsck and remounting the file system, the on-line
> resize will work correctly.

Would it not be easier just to put a test in resize2fs which says "I 
can't do that, please fix your filesystem first" ?

1.42.5 won't try (32 bit limit).
1.42.11 will spin (32 bit overflow)
So just make 1.42.12 abort with an error.

Is it worth having e2fsck check for mis-applied features and flags?
--
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