linux-ext4 - Re: mkfs.ext4 vs. e2fsck discard oddities

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]

Message-ID: <4F5A1E4A.9060804@ubuntu.com>
Date:	Fri, 09 Mar 2012 10:14:18 -0500
From:	Phillip Susi <psusi@...ntu.com>
To:	Lukas Czerner <lczerner@...hat.com>
CC:	Ted Ts'o <tytso@....edu>, Eric Sandeen <sandeen@...hat.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: mkfs.ext4 vs. e2fsck discard oddities

On 3/9/2012 3:59 AM, Lukas Czerner wrote:
> Why would we try to check UNINIT groups with valid descriptor checksums
> ? I think that this problem will be solved with BLOCK_DISCARDED flag as
> we discussed with Ted in another thread. No need to have yet another
> option so it is win-win :)

Because not skipping a specific action on an uninitialized group ( 
discard ) is a specific case of the more general form of not skipping 
uninitialized groups.  I thought that it might sometimes be useful to 
actually verify the group is correct instead of trusting the uninit 
flag, especially if you are about to discard it.  Also any other things 
that are added in the future and skipped for uninit groups would not 
need yet another flag to specifically not skip that action, since it 
will be covered by the more general flag already.

Also the way the code was structured it looked like it would be much 
simpler to bypass the skip and do the full check of the uninit group 
than to modify it to discard the group even though checking it was skipped.

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