linux-ext4 - Re: [Ocfs2-devel] [PATCH] [RFC] jbd2: Add buffer triggers

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: <20081008231752.GA5310@mail.oracle.com>
Date:	Wed, 8 Oct 2008 16:17:52 -0700
From:	Joel Becker <Joel.Becker@...cle.com>
To:	Theodore Tso <tytso@....edu>, ocfs2-devel@....oracle.com,
	linux-ext4@...r.kernel.org, mfasheh@...e.com
Subject: Re: [Ocfs2-devel] [PATCH] [RFC] jbd2: Add buffer triggers

On Mon, Oct 06, 2008 at 06:01:54PM -0700, Joel Becker wrote:
> On Mon, Oct 06, 2008 at 07:32:48PM -0400, Theodore Tso wrote:
> > On Mon, Oct 06, 2008 at 02:42:52PM -0700, Joel Becker wrote:
> > I'm not 100% sure.....  The other area that we should check very
> > closely is jbd2_journal_commit_transaction(); in some cases, if
> > jh->b_committed_data is NULL, the frozen data is thrown away (around
> > line 850 in transaction.c).  I *think* this happens if b_frozen_data
> > was only copied to escape the buffer, but I'm not certain; in any
> > case, there's a potential that in that case you might lose the
> > calculated checksum and the correct value wouldn't get written to the
> > final location on disk.  
<snip>
> 	Looking at the checkpoint part, though, I think we're not safe.
> The buffer is attached to the original transaction's checkpoint list
> after the commit.  This buffer has the un-checksummed b_data.  If the
> later transaction commits before the checkpoint happens, all is good.
> But if the buffer lazily writes to disk while the later transaction is
> still running, the original transaction could be considered "done",
> updating the journal superblock.  If we crash at that moment, we have a
> bad checksum on disk.

	I chatted with Mark some about this today.  He pointed out that,
logically, b_data can't be checkpointed until its data isn't in the
journal - it might be newer than the most recent transaction.  So I
looked in the checkpoint code to see where this is handled, and the
checkpoint code simply forces a commit new enough to encompass b_data
when it wants to put that block to disk.
	In other words, I think that the commit trigger is safe in all
circumstances once moved up in journal_commit_transaction().  I'll be
cooking that up shortly.

Joel

-- 

To spot the expert, pick the one who predicts the job will take the
longest and cost the most.

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@...cle.com
Phone: (650) 506-8127
--
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