Hi, On Tue, 2006-04-11 at 15:35 +0200, Jan Kara wrote: > 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. Bitmaps can never be freed. But the forget list isn't just for freed data: we keep things on the forget list once they are written to the journal, so that on final commit we know which buffers are now safe to be written back to the main backing store. > Now if bitmap > buffer is processed first, we switch to new bitmap (hence the buffer > freed by this transaction is again available for allocation). Bitmaps are statically allocated. The buffer can be *journaled* again, though, sure. But it's never deallocated, nor is the data "switch"ed: the b_frozen_data and b_committed_data pointers are only ever copies of b_data, b_data never changes. > If we > reschedule on that cond_resched_lock() and in the meantime someone > allocates the buffer, we later fail with that assertion failure. I'm not sure what's supposed to be special about bitmap buffers in this context. The only difference in this loop should be that block bitmaps are the only kind of buffer which can have b_committed_data set. This has implications for the lifetime of the b_frozen_data copy, but other than that, not for the lifetime of the bh/jh itself. > Quick and easy fix to the problem is to just remove that > cond_resched_lock(). I'm still not seeing the fault scenario clearly here. Cheers, Stephen - 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
