"Stephen C. Tweedie" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
