Hi, On Mon, 2005-03-07 at 20:31, Andrew Morton wrote:
> 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. > 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... Right, that was what I was thinking might be possible. But for now I've just done the simple patch --- make sure we don't clear jh->b_transaction when we're just refiling buffers from one list to another. That should have the desired effect here without dangerous messing around with locks. I'm having trouble testing it, though --- I seem to be getting livelocks in O_DIRECT running 400 fsstress processes in parallel; ring any bells? I get it with today's bk tree without any ext3 changes too, so at least it's not a regression. --Stephen - 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/