linux-toradex.git/fs/jbd, branch v2.6.19.2

[PATCH] jbd: journal_dirty_data re-check for unmapped buffers

2006-10-28T18:30:51+00:00

When running several fsx's and other filesystem stress tests, we found
cases where an unmapped buffer was still being sent to submit_bh by the
ext3 dirty data journaling code.

I saw this happen in two ways, both related to another thread doing a
truncate which would unmap the buffer in question.

Either we would get into journal_dirty_data with a bh which was already
unmapped (although journal_dirty_data_fn had checked for this earlier, the
state was not locked at that point), or it would get unmapped in the middle
of journal_dirty_data when we dropped locks to call sync_dirty_buffer.

By re-checking for mapped state after we've acquired the bh state lock, we
should avoid these races.  If we find a buffer which is no longer mapped,
we essentially ignore it, because journal_unmap_buffer has already decided
that this buffer can go away.

I've also added tracepoints in these two cases, and made a couple other
tracepoint changes that I found useful in debugging this.

Signed-off-by: Eric Sandeen 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ext3/4: fix J_ASSERT(transaction->t_updates > 0) in journal_stop()

2006-10-20T17:26:44+00:00

A disk generated some I/O error, after it, I hitted
J_ASSERT(transaction->t_updates > 0) in journal_stop().

It seems to happened on ext3_truncate() path from stack trace. Then,
maybe the following case may trigger J_ASSERT(transaction->t_updates > 0).

ext3_truncate()
    -> ext3_free_branches()
        -> ext3_journal_test_restart()
	    -> ext3_journal_restart()
                -> journal_restart()
                transaction->t_updates--;
                /* another process aborted journal */
                    -> start_this_handle()
		    returns -EROFS without transaction->t_updates++;

    -> ext3_journal_stop()
        -> journal_stop()
	J_ASSERT(transaction->t_updates > 0)

If journal was aborted in middle of journal_restart(), ext3_truncate()
may trigger J_ASSERT().

Signed-off-by: OGAWA Hirofumi 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] null dereference in fs/jbd/journal.c

2006-10-11T18:14:14+00:00

Since commit d1807793e1e7e502e3dc047115e9dbc3b50e4534 we dereference a NULL
pointer.  Coverity id #1432.  We set journal to NULL, and use it directly
afterwards.

Signed-off-by: Eric Sesterhenn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fix file specification in comments

2006-10-03T21:01:26+00:00

Many files include the filename at the beginning, serveral used a wrong one.

Signed-off-by: Uwe Zeisberger 
Signed-off-by: Adrian Bunk

[PATCH] JBD: memory leak in "journal_init_dev()"

2006-09-29T16:18:03+00:00

We leak a bh ref in "journal_init_dev()" in case of failure.

Signed-off-by: Zoltan Menyhart 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] JBD: Make journal_brelse_array() static

2006-09-29T16:18:03+00:00

It's always good to make symbols static when we can, and this also eliminates
the need to rename the function in jbd2

Suggested by Eric Sandeen.

Signed-off-by: Dave Kleikamp 
Cc: Eric Sandeen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ext3: Fix sparse warnings

2006-09-27T15:26:10+00:00

Fixing up some endian-ness warnings in preparation to clone ext4 from ext3.

Signed-off-by: Dave Kleikamp 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ext3: More whitespace cleanups

2006-09-27T15:26:10+00:00

More white space cleanups in preparation of cloning ext4 from ext3.
Removing spaces that precede a tab.

Signed-off-by: Dave Kleikamp 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] JBD: 16T fixes

2006-09-27T15:26:09+00:00

These are a few places I've found in jbd that look like they may not be
16T-safe, or consistent with the use of unsigned longs for block
containers.  Problems here would be somewhat hard to hit, would require
journal blocks past the 8T boundary, which would not be terribly common.
Still, should fix.

(some of these have come from the ext4 work on jbd as well).

I think there's one more possibility that the wrap() function may not be
safe IF your last block in the journal butts right up against the 232 block
boundary, but that seems like a VERY remote possibility, and I'm not
worrying about it at this point.

Signed-off-by: Eric Sandeen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] jbd: use BUILD_BUG_ON in journal init

2006-09-27T15:26:09+00:00

Signed-off-by: Alexey Dobriyan 
Acked-by: Stephen Tweedie 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds