public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Fasheh <mark.fasheh@oracle.com>
To: linux-kernel@vger.kernel.org
Cc: akpm@osdl.org, sct@redhat.com
Subject: [PATCH] kjournald() missing JFS_UNMOUNT check
Date: Mon, 11 Jul 2005 14:19:26 -0700	[thread overview]
Message-ID: <20050711211926.GC14505@ca-server1.us.oracle.com> (raw)

Hi,
	Can we please merge this patch? I sent it to ext2-devel for comments
last week and haven't hear anything back. It seems trivially correct and is
testing fine - famous last words, I know :)

My original mail follows:

	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.
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com

--- ../linux-2.6.13-rc1-ro/fs/jbd/journal.c	2005-06-28 22:57:29.000000000 -0700
+++ linux-2.6.13-rc1/fs/jbd/journal.c	2005-07-07 12:01:44.280714000 -0700
@@ -193,6 +193,8 @@
 		if (transaction && time_after_eq(jiffies,
 						transaction->t_expires))
 			should_sleep = 0;
+		if (journal->j_flags & JFS_UNMOUNT)
+ 			should_sleep = 0;
 		if (should_sleep) {
 			spin_unlock(&journal->j_state_lock);
 			schedule();

             reply	other threads:[~2005-07-11 21:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-11 21:19 Mark Fasheh [this message]
2005-07-12 16:59 ` [PATCH] kjournald() missing JFS_UNMOUNT check Stephen C. Tweedie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050711211926.GC14505@ca-server1.us.oracle.com \
    --to=mark.fasheh@oracle.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sct@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox