Jan Kara <jack@xxxxxxx> wrote: > > Hello, > > I think I have found a possible cause of assertion failure in > journal_commit_buffer() on line 793 (b_next_transaction == NULL) (which you mean journal_commit_transaction(). > was reported about two times as I remember). And I think the problem is > just a few lines below in cond_resched_lock(&journal->j_list_lock); > The problem is following: we are processing t_forget list of a > committing transaction. On this forget list are among other buffers also > bitmaps and buffers that are freed by this transaction. Now if bitmap > buffer is processed first, we switch to new bitmap (hence the buffer > freed by this transaction is again available for allocation). If we > reschedule on that cond_resched_lock() and in the meantime someone > allocates the buffer, we later fail with that assertion failure. I assume you're referring to the cond_resched_lock() at line 799. I don't really follow your description here (it seems to be missing bits), but that loop drops that lock in other places - why wouldn't those places also be vulnerable? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
