linux-ext4 - Re: [PATCH v2] ext4: fix initialization of UNINIT bitmap blocks

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: <20080924162339.GH9929@mit.edu>
Date:	Wed, 24 Sep 2008 12:23:39 -0400
From:	Theodore Tso <tytso@....edu>
To:	Frédéric Bohé <frederic.bohe@...l.net>
Cc:	Andreas Dilger <adilger@....com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH v2] ext4: fix initialization of UNINIT bitmap blocks

On Wed, Sep 24, 2008 at 02:57:28PM +0200, Frédéric Bohé wrote:
> 
> You are right ext4_group_info structure was not as big as I thought.
> Do you mean that making ext4_group_info generic for both mballoc and
> oldalloc will reduce the code complexity ?

Long-term, we want to do this, yes.  There's a lot of stuff in mballoc
that we probably need to move out into generic code.  I'll sending
patches shortly that move the /proc handling code into the generic
code, and also saving 2k of compiled object code in the process.

Here, I think main argument is since mballoc is on by default, and the
benefits of this are huge, is that we would save memory by using an
unused bit in ext4_group_info.

A related question is at what point should we remove the oldalloc code
altogehter?

> > Also, if you are considering this approach (to initialize the in-memory
> > bitmaps at mount time) they should be written to disk even if unused.
> > Please also consider doing the inode table zeroing at the same time.
> > This would allow uninit_bg to avoid doing it at mke2fs time.
> 
> In fact, I was not considering doing this at mount time, but it could be
> a good approach.
> Anyway, I don't understand why we should write bitmaps to disk after
> that, and why we should zeroing the inode table.  Don't we end up with a
> fast mkfs and a slow mount doing all the stuff older mkfs was doing ?
> The UNINIT feature would become less interesting.

It would be an absolute disaster to do this at mount time, especially
if it included zeroing the inode table.  Zeroing the inode table must
be done in a background kernel thread, with appropriate locks to avoid
races with the block allocation code (this is one of the places where
eliminating the old allocation code would make life easier).

I don't think we should worry about initializing the bitmaps in
advance.  There's just no advantage in doing that for the bitmaps.
For the inode table we want to do this for safety's sake, but that's
not a concern for the bitmaps.

						- 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