linux-ext4 - RE: [PATCH 40/74] libext2fs: no need to clear BLOCK_UNINIT during ext2fs_reserve_super_and

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 for Android: free password hash cracker in your pocket

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

Message-ID: <28989C0C9F1C0A428470D967B5FCED3723FABD@BPXM22GP.gisp.nec.co.jp>
Date:	Fri, 10 Jan 2014 08:17:56 +0000
From:	Akira Fujita <a-fujita@...jp.nec.com>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>,
	"tytso@....edu" <tytso@....edu>
CC:	Akira Fujita <a-fujita@...jp.nec.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: RE: [PATCH 40/74] libext2fs: no need to clear BLOCK_UNINIT during
 ext2fs_reserve_super_and_bgd

Hi,

>Now that we've trained libext2fs to have this same behavior whenever
>it's loading a block bitmap, we no longer need to unset BLOCK_UNINIT
>for a group that contains only its own group metadata -- kernel,
>e2fsck, and e2fsprogs will handle this correctly.

It seems to me that the problem (*) I reported is not fixed
after applying your 38-41 patches. Do we need extra patch for this?

(*)
http://marc.info/?l=linux-ext4&m=138242796915518&w=2

Regards,
Akira Fujita

>From: Darrick J. Wong [mailto:darrick.wong@...cle.com]
>Sent: Wednesday, December 11, 2013 10:23 AM
>To: tytso@....edu; darrick.wong@...cle.com
>Cc: Akira Fujita; linux-ext4@...r.kernel.org
>Subject: [PATCH 40/74] libext2fs: no need to clear BLOCK_UNINIT during ext2fs_reserve_super_and_bgd
>
>Since the beginning of the uninit_bg feature, the kernel[1] and
>e2fsck[2] have always been careful to detect the presence of the
>BLOCK_UNINIT flag, and compute a block bitmap with any group metadata
>blocks marked in that bitmap.  With that in mind, I think it's safe to
>say that this is a design feature of uninit_bg.
>
>Now that we've trained libext2fs to have this same behavior whenever
>it's loading a block bitmap, we no longer need to unset BLOCK_UNINIT
>for a group that contains only its own group metadata -- kernel,
>e2fsck, and e2fsprogs will handle this correctly.
>
>[1] kernel git 717d50e4971b81b96c0199c91cdf0039a8cb181a
>    "Ext4: Uninitialized Block Groups"
>[2] e2fsprogs git f5fa20078bfc05b554294fe9c5505375d7913e8c
>    "Add support for EXT2_FEATURE_COMPAT_LAZY_BG"
>
>Reported-by: Akira Fujita <a-fujita@...jp.nec.com>
>Signed-off-by: Darrick J. Wong <darrick.wong@...cle.com>
>---
> lib/ext2fs/alloc_sb.c |    2 --
> 1 file changed, 2 deletions(-)
>
>
>diff --git a/lib/ext2fs/alloc_sb.c b/lib/ext2fs/alloc_sb.c
>index 223ec51..8788c00 100644
>--- a/lib/ext2fs/alloc_sb.c
>+++ b/lib/ext2fs/alloc_sb.c
>@@ -65,8 +65,6 @@ int ext2fs_reserve_super_and_bgd(ext2_filsys fs,
> 		ext2fs_mark_block_bitmap2(bmap, 0);
>
> 	if (old_desc_blk) {
>-		if (fs->super->s_reserved_gdt_blocks && fs->block_map == bmap)
>-			ext2fs_bg_flags_clear(fs, group, EXT2_BG_BLOCK_UNINIT);
> 		num_blocks = old_desc_blocks;
> 		if (old_desc_blk + num_blocks >= ext2fs_blocks_count(fs->super))
> 			num_blocks = ext2fs_blocks_count(fs->super) -