Re: [RFC] ext3/jbd race: releasing in-use journal_heads

[Stephen C. Tweedie]

Hi,

On Sat, 2005-03-05 at 00:04, Andrew Morton wrote:

> Perhaps we could also fix this by elevating b_jcount whenever the jh is
> being moved between lists?

Possible.  But jcount isn't atomic, and it requires the bh_journal_head
lock to modify.  Taking and dropping the lock twice around the
__unfile/__refile pair, once to inc jcount and once again to drop it, is
probably unnecessarily expensive.  We can probably do with just holding
the bh_journal_head lock alone in most cases.

The specific case we're stumbling on here is the t_locked_list.  The
problem manifests itself when we walk that list, but we think it is
actually caused when we first add it to the list:

			__journal_unfile_buffer(jh);
			__journal_file_buffer(jh, commit_transaction,
						BJ_Locked);

__journal_unfile_buffer does no locking of its own.  We're calling this
point with the buffer locked, j_list_lock held and the bh_state lock
held.

Trouble is, that's not enough; journal_put_journal_head() can nuke the
buffer with merely the bh_journal_head lock held.  In the code above it
would be enough to take the journal_head_lock over the unfile/file pair.

Andrew, can you remember why we ended up with both of those locks in the
first place?  If we can do it, the efficient way out here is to abandon
the journal_head_lock and use the bh_state_lock for both.  We already
hold that over many of the key refile spots, and this would avoid the
need to take yet another lock in those paths.

--Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/