linux-ext4 - Re: [PATCH 2/2] ext4: Automatically enable journal_async

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: <20090908044541.GF22901@mit.edu>
Date:	Tue, 8 Sep 2009 00:45:41 -0400
From:	Theodore Tso <tytso@....edu>
To:	Ric Wheeler <ricwheeler@...il.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 2/2] ext4: Automatically enable journal_async_commit on
	ext4 file systems

On Mon, Sep 07, 2009 at 07:42:58PM -0400, Ric Wheeler wrote:
>
> I am not sure that we are really good with ASYNC commit being on all of  
> the time - I really worry that we will see lots of issues.

There really isn't much difference between async commit and non-async
commit.  In fact, the name is really a bit of a misnomer at this
point.

So here's what we do on a non-async commit:

1)  Write the journal data, revoke, and descriptor blocks
2)  Wait for the block I/O layer to signal that all of these blocks 
    have been written out --- *without* a barrier
3)  Write the commit block with a barrier
4)  Wait for the I/O to commit block to be done

This is what we do with an async commit:

1)  Write the journal data, revoke, and descriptor blocks
2)  Write the commit block (with a checksum) with a barrier
3)  Wait for the I/O to in steps (1) and (2) to be done

That's the only difference at this point.  The fatal flaw with async
commit from before was this that we weren't writing the commit block
in step (2) with a barrier --- and that *was* disastrous, since it
meant the equivalent of mounting with barrier=0.

But now that it is fixed, this code path does make sense, and given
that we weren't inserting a barrier between steps 2 and 3, we were in
fact (theoretically) vulnerable to the commit block and the journal
blocks getting reordered in 2.6.30 and older kernels.  Turning on the
journal checksum (in the prior commit) helps solve that issue, but at
that point, we might as well write the commit block before we start
waiting on all of the journal blocks.

As far as the code complexity issue concern, it really wasn't that
complicated, and in fact we're not really changing the existing code
path that we've been using for over a year now by very much.  The only
difference in fact is where we call the function to write the commit
record.

						- 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