tree 327deb90d3e77bf65189ff41c6121e2e865537ea
parent 3870ee8c63d5e55aea990654dfeb231264e13134
author Mark Fasheh <[EMAIL PROTECTED]> Wed, 07 Sep 2005 05:19:08 -0700
committer Linus Torvalds <[EMAIL PROTECTED]> Thu, 08 Sep 2005 06:57:54 -0700

[PATCH] kjournald: missing JFS_UNMOUNT check

It seems that kjournald() may be missing a check of the JFS_UNMOUNT flag
before calling schedule().  This showed up in testing of OCFS2 recovery
where our recovery thread would hang in journal_kill_thread() called from
journal_destroy() because kjournald never got a chance to read the flag to
shut down before the schedule().

Zach pointed out the missing check which led me to hack up this trivial
patch.  It's been tested many times now and I have yet to reproduce the
hang, which was happening very regularly before.

<mild rant>
I'm guessing that we could really use some wait_event() calls with helper
functions in, well, most of jbd these days which would make a ton of the
wait code there vastly cleaner.
</mild rant>

As for why this doesn't happen in ext3 (or OCFS2 during normal
mount/unmount of the local nodes journal), I think it may that the specific
timing of events in the ocfs2 recovery thread exposes a race there.
Because ocfs2_replay_journal() is only interested in playing back the
journal, initialization and shutdown happen very quicky with no other
metadata put into that specific journal.

Acked-by: "Stephen C. Tweedie" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>

 fs/jbd/journal.c |    2 ++
 1 files changed, 2 insertions(+)

diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -179,6 +179,8 @@ loop:
                if (transaction && time_after_eq(jiffies,
                        should_sleep = 0;
+               if (journal->j_flags & JFS_UNMOUNT)
+                       should_sleep = 0;
                if (should_sleep) {
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to