public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: yangerkun <yangerkun@huawei.com>
Cc: jack@suse.cz, linux-ext4@vger.kernel.org, yukuai3@huawei.com
Subject: Re: [PATCH] ext4: flush s_error_work before journal destroy in ext4_fill_super
Date: Fri, 23 Jul 2021 15:11:33 -0400	[thread overview]
Message-ID: <YPsUZX+PF5HASRkK@mit.edu> (raw)
In-Reply-To: <eb962c26-b013-957b-7931-feda7f8bf5b5@huawei.com> <c0c8619d-3d9b-a184-3cd1-0cd88447fdcd@huawei.com>

On Fri, Jul 23, 2021 at 09:11:08PM +0800, yangerkun wrote:
> 
> For example, before wo goto failed_mount_wq, we may meet some error and will
> goto ext4_handle_error which can call
> schedule_work(&EXT4_SB(sb)->s_error_work). So the work may start concurrent
> with ext4_fill_super goto failed_mount_wq. There does not have any lock to
> protect the concurrent read and modifies for sbi->s_journal.

Yes, and I'm asking *how* is this actually happening in practice?
I've been going through the code paths and I don't see any place where
ext4_error*() would be called.  That's why I wanted to see your test
case which was reproducing it.  (Not just where you added the msleep,
but how the error was getting triggered in the first place.)


On Fri, Jul 23, 2021 at 09:25:12PM +0800, yangerkun wrote:
> 
> > Can you share with me your test case?  Your patch will result in the
> > shrinker potentially not getting released in some error paths (which
> > will cause other kernel panics), and in any case, once the journal is
> 
> The only logic we have changed is that we move the flush_work before we call
> jbd2_journal_destory. I have not seen the problem you describe... Can you
> help to explain more...

Sorry, I was mistaken.  I thought you were moving the
ext4_es_unregister_shrinker() and flush_work() before the label for
failed_mount_wq; that was a misreading of your patch.

The other way we could fix this might be something like this:

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index dfa09a277b56..d663d11fa0de 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -693,7 +693,7 @@ static void flush_stashed_error_work(struct work_struct *work)
 {
 	struct ext4_sb_info *sbi = container_of(work, struct ext4_sb_info,
 						s_error_work);
-	journal_t *journal = sbi->s_journal;
+	journal_t *journal = READ_ONCE(sbi->s_journal);
 	handle_t *handle;
 
 	/*
@@ -1184,9 +1184,11 @@ static void ext4_put_super(struct super_block *sb)
 	ext4_unregister_sysfs(sb);
 
 	if (sbi->s_journal) {
-		aborted = is_journal_aborted(sbi->s_journal);
-		err = jbd2_journal_destroy(sbi->s_journal);
-		sbi->s_journal = NULL;
+		journal_t *journal = sbi->s_journal;
+
+		WRITE_ONCE(sbi->s_journal, NULL);
+		aborted = is_journal_aborted(journal);
+		err = jbd2_journal_destroy(journal);
 		if ((err < 0) && !aborted) {
 			ext4_abort(sb, -err, "Couldn't clean up the journal");
 		}
@@ -5175,8 +5177,10 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
 	sbi->s_ea_block_cache = NULL;
 
 	if (sbi->s_journal) {
-		jbd2_journal_destroy(sbi->s_journal);
-		sbi->s_journal = NULL;
+		journal_t *journal = sbi->s_journal;
+
+		WRITE_ONCE(sbi->s_journal, NULL);
+		jbd2_journal_destroy(journal);
 	}
 failed_mount3a:
 	ext4_es_unregister_shrinker(sbi);
@@ -5487,7 +5491,7 @@ static int ext4_load_journal(struct super_block *sb,
 	EXT4_SB(sb)->s_journal = journal;
 	err = ext4_clear_journal_err(sb, es);
 	if (err) {
-		EXT4_SB(sb)->s_journal = NULL;
+		WRITE_ONCE(EXT4_SB(sb)->s_journal, NULL);
 		jbd2_journal_destroy(journal);
 		return err;
 	}

... and here's another possible fix:

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index dfa09a277b56..e9e122e52ce8 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -704,7 +704,8 @@ static void flush_stashed_error_work(struct work_struct *work)
 	 * We use directly jbd2 functions here to avoid recursing back into
 	 * ext4 error handling code during handling of previous errors.
 	 */
-	if (!sb_rdonly(sbi->s_sb) && journal) {
+	if (!sb_rdonly(sbi->s_sb) && journal &&
+	    !(journal->j_flags & JBD2_UNMOUNT)) {
 		struct buffer_head *sbh = sbi->s_sbh;
 		handle = jbd2_journal_start(journal, 1);
 		if (IS_ERR(handle))



But I would be interested in understanding how we could be triggering
this problem in the first place before deciding what's the best fix.

Cheers,

					- Ted

  reply	other threads:[~2021-07-23 19:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20  6:24 [PATCH] ext4: flush s_error_work before journal destroy in ext4_fill_super yangerkun
2021-07-23 12:11 ` Theodore Ts'o
2021-07-23 13:11   ` yangerkun
2021-07-23 19:11     ` Theodore Ts'o [this message]
2021-07-26  7:13       ` yangerkun
2021-07-26 13:26         ` Jan Kara
2021-08-03 11:13           ` yangerkun
2021-07-23 13:25   ` yangerkun
2021-08-24 10:11     ` yangerkun

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=YPsUZX+PF5HASRkK@mit.edu \
    --to=tytso@mit.edu \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yukuai3@huawei.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