linux-ext4 - group descriptor contents and LAZY

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

Message-ID: <20070324214056.GL5967@schatzie.adilger.int>
Date:	Sat, 24 Mar 2007 15:40:57 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org
Cc:	Girish Shilamkar <girish@...syssoft.com>,
	Kalpak Shah <kalpak@...sterfs.com>
Subject: group descriptor contents and LAZY_BG

Ted,
the LAZY_BG feature was originally written to test large filesystems and
avoid the need to format (or even allocate, if sparse) large parts of the
inode table and bitmaps.  To make the feature COMPAT the bg_free_blocks_count
and bg_free_inodes_count are initialized to zero, and the kernel will skip
these groups entirely without checking the bitmap.

For the GDT_CSUM feature, we are using the LAZY_BG feature to not initialize
the bitmaps and inode table.  However, setting the bg_free_*_count to zero
is troublesome because it means we always need to check the GDT_CSUM feature
flag to know whether a group actually has free blocks/inodes, and e2fsck
is also getting confused about the number of free blocks/inodes in the groups
and filesystem (we have to have a double accounting for "real" free blocks
and "uninitialized" free blocks.

What do you think for the GDT_CSUM feature that we initialize the group
descriptors as if the group had actually been formatted?  I think our
use of the LAZY_BG feature is actually misguided - while they share some
components (e.g. UNINIT flags, mke2fs code, some e2fsck code), since the
GDT_CSUM feature is RO_COMPAT there isn't much reason to even enable
LAZY_BG at format time...

We have to replace all uses of bg_free_*_count with the below macros:

+/* Macro-instructions used to calculate Free inodes and blocks count. */
+#define EXT3_BG_INODES_FREE(sb,gr,gdp) ((EXT3_HAS_RO_COMPAT_FEATURE(sb,       \
+					  EXT4_FEATURE_RO_COMPAT_GDT_CSUM) &&  \
+					  (gdp)->bg_flags & 		       \
+				          cpu_to_le16(EXT3_BG_INODE_UNINIT)) ? \
+				       EXT3_INODES_PER_GROUP(sb) :	       \
+				       le16_to_cpu((gdp)->bg_itable_unused) +  \
+				       le16_to_cpu((gdp)->bg_free_inodes_count))
+#define EXT3_BG_BLOCKS_FREE(sb,gr,gdp) ((EXT3_HAS_RO_COMPAT_FEATURE(sb,       \
+					  EXT4_FEATURE_RO_COMPAT_GDT_CSUM) &&  \
+					  (gdp)->bg_flags & 		       \
+				          cpu_to_le16(EXT3_BG_BLOCK_UNINIT)) ? \
+				       ext3_free_blocks_after_init(sb,gr,gdp) :\
+				       le16_to_cpu((gdp)->bg_free_blocks_count))

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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