Messages in this thread |  | | From | Alex Tomas <> | Subject | Re: [Ext2-devel] [RFC] probably bug in current ext3/jbd | Date | Tue, 20 May 2003 00:46:34 +0000 |
| |
hi!
please, look:
thread A commit thread
if (jh->b_committed_data) { kfree(jh->b_committed_data); jh->b_committed_data = NULL; } access for b_committed_data == NULL ?
if (jh->b_frozen_data) { jh->b_committed_data = jh->b_frozen_data; jh->b_frozen_data = NULL; }
or I miss something subtle here?
>>>>> Stephen C Tweedie (SCT) writes:
SCT> get_undo_access is a declaration of intention to modify the buffer. SCT> When that happens, it calls do_get_write_access() with the force_copy SCT> flag set. That means that it _always_ creates a new frozen_data copy of SCT> the buffer the first time we get undo access to a bitmap buffer within SCT> any given transaction. That basically means that for bitmaps, SCT> frozen_data always holds the version of the buffer as of the end of the SCT> previously completed transaction.
>> for_each_bh_in_forget_list() { >> if (jh->b_committed_data) { >> kfree(jh->b_committed_data); jh-> b_committed_data = NULL; >> }
SCT> Ah, but the *immediately* following lines are:
SCT> if (jh->b_frozen_data) { jh-> b_committed_data = jh->b_frozen_data; jh-> b_frozen_data = NULL; SCT> }
SCT> so the frozen data that was preserved at get_undo_access() time has now SCT> committed to disk and gets rotated into the b_committed_data version. SCT> This is exactly how we get the new version of the committed data when SCT> the old transaction commits.
SCT> Cheers, SCT> Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |