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

[Andrew Morton]

"Stephen C. Tweedie" <sct@xxxxxxxxxx> wrote:
>
> 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.

Oh gosh.  It was a transformation from the global journal_datalist_lock and
jh_splice_lock locks.  jbd_lock_bh_journal_head() is supposed to be a
finegrained innermost lock whose mandate is purely for atomicity of adding
and removing the journal_head and the b_jcount refcounting.  I don't recall
there being any deeper meaning than that.

The original changelog says:

  buffer_heads and journal_heads are joined at the hip.  We need a lock to
  protect the joint and its refcounts.
  
  JBD is currently using a global spinlock for that.  Change it to use one bit
  in bh->b_state.

It could be that we can optimise jbd_lock_bh_journal_head() away, as you
mention.  If we have an assertion in there to check that
jbd_lock_bh_state() is held...
-
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/