linux-ext4 - Re: mke2fs and lazy_itable

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: <20080509021827.GA8871@mit.edu>
Date:	Thu, 8 May 2008 22:18:27 -0400
From:	Theodore Tso <tytso@....EDU>
To:	Andreas Dilger <adilger@....com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: mke2fs and lazy_itable_init

On Thu, May 08, 2008 at 04:48:47PM -0600, Andreas Dilger wrote:
> I just noticed lazy_itable_init in the mke2fs.8.in man page.  I think
> a warning needs to be added there that this is not currently safe to
> use, because the kernel does not yet do the background zeroing.  There
> is nothing in the man page to indicate that this is unsafe...

Yeah, I was hoping we would actually get this fixed before 1.41 was
released....  (i.e., implement the background zeroing).  One of the
things I was thinking about was whether we could avoid needing to go
through the jbd layer when zeroing out an entire inode table block,
and then in the completion callback function when the block group was
completely initiaized, we could clear the ITABLE_UNINIT flag.

It doesn't need to go through the journal, because if we crash without
having the flag set, its not a big deal; the inode table will just not
be marked initialized.  The only thing which might require a little
care is if buffer head referencing part of the inode table which is
getting zero'ed out is in flight when an inode allocation happens, an
inode gets marked dirty, and fs/ext4/inode.c wants to write out an
inode table block that is in the middle of being zero'ed.  Given that
we've bypassed the jbd layer for efficiency's sake, something bad
could happy unless we protect it with some kind of lock.

Or we could just say that this initialization pass is relatively rare,
so do it the cheap cheasy way, even if the blocks end up going through
the journal.  The upside is that it should be pretty quick and easy to
code it this way.

					- 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