linux-ext4 - Re: What's cooking in e2fsprogs.git (topics)

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: <20080305105950.41510584@gara>
Date:	Wed, 5 Mar 2008 10:59:50 -0600
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Theodore Tso <tytso@....EDU>, Andreas Dilger <adilger@....com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: What's cooking in e2fsprogs.git (topics)

On Fri, 29 Feb 2008 10:43:33 -0500
Theodore Tso <tytso@....EDU> wrote:
> Block bitmap differences:  +8195Group 3 block(s) in use but group is marked BLO
> CK_UNINIT
> Fix? yes
> 
> 	This mangling is happening because error reporting for
> 	PR_5_INODE_UNINIT is getting intermingled with the
> 	PR_5_INODE_USED/PR_5_INODE_UNUSED reporting, which isn't a
> 	good idea.  The comment around the code says:
> 
> 		/* 
> 		 * We should never hit this, because it means that
> 		 * inodes were marked in use that weren't noticed
> 		 * in pass1 or pass 2. It is easier to fix the problem
> 		 * than to kill e2fsck and leave the user stuck.
> 		 */
> 
> 	So I'm guessing there's something else wrong going on here....

After looking at the misc/mke2fs.c a second time, I notice that there
is one chunk missing in setup_lazy_bg from the 6270612c commit:

+
+                       /* Skip groups with GDT backups because the resize
+                        * inode has blocks allocated in them, and the last
+                        * group because it needs block bitmap padding. */
+                       if ((ext2fs_bg_has_super(fs, i) &&
+                            sb->s_reserved_gdt_blocks) ||
+                           i == fs->group_desc_count - 1)
+                               continue;
+

This should fix the problem you see above.  Now, I wonder if you would
see a similar problem if the filesystems is created with the meta_bg
option since we don't check to see if the block groups has a bgd.

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