Messages in this thread | | | Subject | Re: [Ext2-devel] [RFC] probably bug in current ext3/jbd | From | "Stephen C. Tweedie" <> | Date | 19 May 2003 21:34:42 +0100 |
| |
Hi,
On Sun, 2003-05-18 at 18:21, Alex Tomas wrote:
> ext3/jbd use b_committed_data buffer in order to prevent > allocation of blocks which were freed in non-committed > transaction. I think there is bug in this code. look,
You just found a rather subtle bug which was fixed around 2 or 3 years ago. :-)
> some thread commit thread > ----------------------------------------------------------
> start_journal() > get_undo_access(#1): > 1) wait for #1 to be > in t_forget_list
get_undo_access is a declaration of intention to modify the buffer. When that happens, it calls do_get_write_access() with the force_copy flag set. That means that it _always_ creates a new frozen_data copy of the buffer the first time we get undo access to a bitmap buffer within any given transaction. That basically means that for bitmaps, frozen_data always holds the version of the buffer as of the end of the previously completed transaction.
> for_each_bh_in_forget_list() { > if (jh->b_committed_data) { > kfree(jh->b_committed_data); > jh->b_committed_data = NULL; > }
Ah, but the *immediately* following lines are:
if (jh->b_frozen_data) { jh->b_committed_data = jh->b_frozen_data; jh->b_frozen_data = NULL; }
so the frozen data that was preserved at get_undo_access() time has now committed to disk and gets rotated into the b_committed_data version. This is exactly how we get the new version of the committed data when the old transaction commits.
Cheers, 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/
| |