Re: [Ext2-devel] [RFC] probably bug in current ext3/jbd

[Alex Tomas <bzzz@tmi.comex.ru>]

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