Re: [RFC] Bug in journal_commit_transaction?

["Stephen C. Tweedie" <sct@redhat.com>]

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