linux-ext4 - Re: [PATCH] mke2fs: Fix block bitmaps initalization with -O ^resize

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: <20131205020340.GA8404@thunk.org>
Date:	Wed, 4 Dec 2013 21:03:40 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	Akira Fujita <a-fujita@...jp.nec.com>,
	'ext4 development' <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] mke2fs: Fix block bitmaps initalization with -O
 ^resize_inode

On Wed, Dec 04, 2013 at 05:22:10PM -0800, Darrick J. Wong wrote:
> > 2) The IETF rule of "be conservative in what you send, and liberal in
> > what you accept" applies.
> 
> I'm not convinced that we /need/ Akira's patch to clear BLOCK_UNINIT on any
> group containing its own metadata, but I doubt it'd harm anything other than
> make e2fsck slower.
> 
> It would certainly be the conservative-send route though.

The place where we are being conserviative what we send is that we
clear BLOCK_UNINIT for block groups that don't have any data blocks,
but which has metadata blocks belonging to *other* block groups,
because there were some kernel implementations in the past that didn't
handle this correctly.

But if you have a block group that has only its metadata, that's
perfectly fine.  And that's easy to test; if you create a file system
like this:

     touch /tmp/foo.img
     mke2fs -t ext2 -O uninit_bg /tmp/foo.img 1800000

... then by definition every single block group has its own metadata,
and if there were problems with block groups that had its own metadata
blocks, we wouldn't be able to set BLOCK_UNINIT on any block group at
all.

It looks like we are currently clearing BLOCK_UNINIT for block groups
that contain superblocks and backup superblocs.  To be honest, I don't
remember why we are currently doing this.  I *think* the kernel and
all modern e2fsprogs should be able to do the right thing, if we set
BLOCK_UNINIT on all block groups.

				- 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