linux-ext4 - Re: [PATCH][e2fsprogs] New bitmap and inode table allocation for FLEX

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]

Date:	Fri, 4 Apr 2008 00:37:57 -0500
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Theodore Tso <tytso@....EDU>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH][e2fsprogs] New bitmap and inode table allocation for
 FLEX_BG

On Thu, 3 Apr 2008 23:24:43 -0400
Theodore Tso <tytso@....EDU> wrote:

> On Thu, Apr 03, 2008 at 09:28:58AM -0500, Jose R. Santos wrote:
> > I blame Undo Manager for being so slow that cause me to skip some of
> > the testing needed to be done.  
> 
> If that means we need a patch to disable the undo manager, via a
> command-line option, feel free.  :-)

Im sufficiently annoyed that I may just do that.

> > I was incorrectly checking the feature
> > flag instead of checking the value of fs->super->s_log_groups_per_flex.
> 
> Actually, you should check both, and we need to make mke2fs have an
> intelligent default, which can be overridden via mke2fs.conf.

Yes it should check both(will fix).  I was expecting more people to
give flexbg a test before trying to determined an intelligent default
though.

> Also, it looks like this patch doesn't create a valid filesystem in
> combination with meta_bg:
> 
> mke2fs G 32 -O meta_bg,flex_bg,uninit_groups,^resize_inode /tmp/foo.img
> 
> Then try running "e2fsck -f /tmp/foo.img" with the patch applied.

Wow, it really breaks.  Throws e2fsck into an infinite loop.

> One obvious question is why is this patch so fragile....?  Is there
> some way we can make it more likely not to break given other changes
> to e2fsprogs in the future.

Getting the right free block count for every group descriptor seems to
be the tricky part since libe2fs make all sort of assumptions about
number of used blocks that break when meta-data is no longer on the
same block group.  Seems like I forgot a check for the adjusted flexbg
block group size in meta_bg since the first place it barfs is in group
127 which is the last group of the meta_bg with a group descriptor
block being used.  This should be easy to find and fix.

> 						- Ted

-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