Hi, On Mon, 2005-03-07 at 14:50, Jan Kara wrote:
> I believe the other places should be safe (mostly by luck) as the > caller has made sure that __journal_remove_journal_head() won't do > anything (e.g. set b_transaction, b_next_transaction or such). Right; I've been looking through all the journal_put_journal_head() callers and most of the instances are places like journal_get_*_access, which imply that the jh is still on a list. The problem is races against places like journal_unmap_buffer() where we can be removing the bh from those lists as soon as we've lost the journal lock. > Anyway it doesn't seem too safe to me... Quite. I think I agree with Andrew here --- the only real solution is to make sure that whenever anybody is clearing jh->b_transaction, they protect themselves against journal_put_journal_head() by either elevating j_count, or taking the jbd_lock_bh_journal_head() lock. The current stop-gap may actually work, but I'd be more comfortable with a robust scheme in place. --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/
