All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Christian Brauner" <brauner@kernel.org>, "Jan Kara" <jack@suse.com>
Cc: "Al Viro" <viro@zeniv.linux.org.uk>,
	linux-ext4@vger.kernel.org, linux-mm@kvack.org,
	linux-efi@vger.kernel.org, linux-mtd@lists.infradead.org,
	dsterba@suse.cz, tytso@mit.edu, "Mark Fasheh" <mark@fasheh.com>,
	"Joel Becker" <jlbec@evilplan.org>,
	"Joseph Qi" <joseph.qi@linux.alibaba.com>
Subject: Re: [PATCH v3 27/33] gfs2: wait for a pending withdraw before remounting read-only
Date: Sat, 14 Nov 2026 12:03:49 +0000	[thread overview]
Message-ID: <sashiko-outbox-214478@kernel.org> (raw)
In-Reply-To: <20261113-work-fs-sb_rdonly-v3-27-0be92bb73709@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] gfs2: hang in gfs2_make_fs_ro() if withdraw occurs before
  SB_BORN
--

commit f8b5b1daf48e3f825a415215536a375fb6cd8b9d
Author: Christian Brauner <brauner@kernel.org>

gfs2: wait for a pending withdraw before remounting read-only

This commit serializes setting SDF_JOURNAL_LIVE in gfs2_make_fs_rw() with
do_withdraw() under sd_log_flush_lock, and makes gfs2_make_fs_ro() wait for
SDF_JOURNAL_LIVE to clear before calling gfs2_quota_cleanup().

> diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
> index 04bb4cf787d4d..f61c309368ef1 100644
> --- a/fs/gfs2/super.c
> +++ b/fs/gfs2/super.c
> @@ -146,12 +146,21 @@ int gfs2_make_fs_rw(struct gfs2_sbd *sdp)
>  	}
>  
>  	error = gfs2_quota_init(sdp);
> -	if (!error && gfs2_withdrawn(sdp)) {
> -		gfs2_quota_cleanup(sdp);
> +	if (error)
> +		return error;
> +
> +	/*
> +	 * Check for a withdraw under the lock do_withdraw() holds while it
> +	 * takes a live journal down, so one of them sees the other.
> +	 */
> +	down_write(&sdp->sd_log_flush_lock);
> +	if (gfs2_withdrawn(sdp))
>  		error = -EIO;
> -	}
> -	if (!error)
> +	else
>  		set_bit(SDF_JOURNAL_LIVE, &sdp->sd_flags);
> +	up_write(&sdp->sd_log_flush_lock);
> +	if (error)
> +		gfs2_quota_cleanup(sdp);
>  	return error;
>  }
>  
> @@ -567,6 +576,9 @@ void gfs2_make_fs_ro(struct gfs2_sbd *sdp)
>  				   HZ * 5);
>  		gfs2_assert_warn(sdp, gfs2_log_is_empty(sdp));
>  	}
> +	/* A withdraw that do_withdraw() didn't finish yet leaves it live. */
> +	if (!test_bit(SDF_NORECOVERY, &sdp->sd_flags))
> +		wait_on_bit(&sdp->sd_flags, SDF_JOURNAL_LIVE, TASK_UNINTERRUPTIBLE);
>  	gfs2_quota_cleanup(sdp);
>  }

[Severity: High]
Can wait_on_bit() in gfs2_make_fs_ro() hang forever if a withdraw happens
during initial mount after gfs2_make_fs_rw() sets SDF_JOURNAL_LIVE, but
before vfs_get_tree() sets SB_BORN?

During initial read-write mount, gfs2_fill_super() starts the logd and
quotad threads, registers the sysfs interface, and calls gfs2_make_fs_rw()
before SB_BORN is set on sb->s_flags.  If gfs2_withdraw() runs after
gfs2_make_fs_rw() sets SDF_JOURNAL_LIVE and before vfs_get_tree() sets
SB_BORN, it sets SDF_WITHDRAWN and returns early without scheduling
sd_withdraw_work:

fs/gfs2/util.c:gfs2_withdraw() {
    ...
		if (test_and_set_bit(SDF_WITHDRAWN, &sdp->sd_flags))
			return;

		dump_stack();
		/*
		 * There is no need to withdraw when the superblock hasn't been
		 * fully initialized, yet.
		 */
		if (!(sdp->sd_vfs->s_flags & SB_BORN))
			return;
		fs_err(sdp, "about to withdraw this file system\n");
		schedule_work(&sdp->sd_withdraw_work);
    ...
}

CPU0 (mount / remount)            CPU1 (kthread / workqueue / sysfs)
vfs_get_tree()
  ...
  gfs2_fill_super()
    gfs2_make_fs_rw()
      set_bit(SDF_JOURNAL_LIVE)
                                  gfs2_withdraw()
                                    test_and_set_bit(SDF_WITHDRAWN)
                                    if (!(s_flags & SB_BORN))
                                      return;
  sb->s_flags |= SB_BORN

gfs2_reconfigure()
  gfs2_make_fs_ro()
    gfs2_log_flush()
      if (gfs2_withdrawn(sdp))
        return;
    wait_on_bit(..., SDF_JOURNAL_LIVE, ...)
      <-- sleeps forever holding sb->s_umount

Because SDF_WITHDRAWN is already set, later calls to gfs2_withdraw() also
return early, so do_withdraw() never runs to clear SDF_JOURNAL_LIVE.  A
subsequent read-only remount bails out of gfs2_log_flush() and blocks
forever in wait_on_bit() with sb->s_umount held in write mode.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113-work-fs-sb_rdonly-v3-0-0be92bb73709@kernel.org?part=27

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Christian Brauner" <brauner@kernel.org>, "Jan Kara" <jack@suse.com>
Cc: "Al Viro" <viro@zeniv.linux.org.uk>,
	linux-ext4@vger.kernel.org, linux-mm@kvack.org,
	linux-efi@vger.kernel.org, linux-mtd@lists.infradead.org,
	dsterba@suse.cz, tytso@mit.edu, "Mark Fasheh" <mark@fasheh.com>,
	"Joel Becker" <jlbec@evilplan.org>,
	"Joseph Qi" <joseph.qi@linux.alibaba.com>
Subject: Re: [PATCH v3 27/33] gfs2: wait for a pending withdraw before remounting read-only
Date: Sat, 14 Nov 2026 12:03:49 +0000	[thread overview]
Message-ID: <sashiko-outbox-214478@kernel.org> (raw)
In-Reply-To: <20261113-work-fs-sb_rdonly-v3-27-0be92bb73709@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] gfs2: hang in gfs2_make_fs_ro() if withdraw occurs before
  SB_BORN
--

commit f8b5b1daf48e3f825a415215536a375fb6cd8b9d
Author: Christian Brauner <brauner@kernel.org>

gfs2: wait for a pending withdraw before remounting read-only

This commit serializes setting SDF_JOURNAL_LIVE in gfs2_make_fs_rw() with
do_withdraw() under sd_log_flush_lock, and makes gfs2_make_fs_ro() wait for
SDF_JOURNAL_LIVE to clear before calling gfs2_quota_cleanup().

> diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
> index 04bb4cf787d4d..f61c309368ef1 100644
> --- a/fs/gfs2/super.c
> +++ b/fs/gfs2/super.c
> @@ -146,12 +146,21 @@ int gfs2_make_fs_rw(struct gfs2_sbd *sdp)
>  	}
>  
>  	error = gfs2_quota_init(sdp);
> -	if (!error && gfs2_withdrawn(sdp)) {
> -		gfs2_quota_cleanup(sdp);
> +	if (error)
> +		return error;
> +
> +	/*
> +	 * Check for a withdraw under the lock do_withdraw() holds while it
> +	 * takes a live journal down, so one of them sees the other.
> +	 */
> +	down_write(&sdp->sd_log_flush_lock);
> +	if (gfs2_withdrawn(sdp))
>  		error = -EIO;
> -	}
> -	if (!error)
> +	else
>  		set_bit(SDF_JOURNAL_LIVE, &sdp->sd_flags);
> +	up_write(&sdp->sd_log_flush_lock);
> +	if (error)
> +		gfs2_quota_cleanup(sdp);
>  	return error;
>  }
>  
> @@ -567,6 +576,9 @@ void gfs2_make_fs_ro(struct gfs2_sbd *sdp)
>  				   HZ * 5);
>  		gfs2_assert_warn(sdp, gfs2_log_is_empty(sdp));
>  	}
> +	/* A withdraw that do_withdraw() didn't finish yet leaves it live. */
> +	if (!test_bit(SDF_NORECOVERY, &sdp->sd_flags))
> +		wait_on_bit(&sdp->sd_flags, SDF_JOURNAL_LIVE, TASK_UNINTERRUPTIBLE);
>  	gfs2_quota_cleanup(sdp);
>  }

[Severity: High]
Can wait_on_bit() in gfs2_make_fs_ro() hang forever if a withdraw happens
during initial mount after gfs2_make_fs_rw() sets SDF_JOURNAL_LIVE, but
before vfs_get_tree() sets SB_BORN?

During initial read-write mount, gfs2_fill_super() starts the logd and
quotad threads, registers the sysfs interface, and calls gfs2_make_fs_rw()
before SB_BORN is set on sb->s_flags.  If gfs2_withdraw() runs after
gfs2_make_fs_rw() sets SDF_JOURNAL_LIVE and before vfs_get_tree() sets
SB_BORN, it sets SDF_WITHDRAWN and returns early without scheduling
sd_withdraw_work:

fs/gfs2/util.c:gfs2_withdraw() {
    ...
		if (test_and_set_bit(SDF_WITHDRAWN, &sdp->sd_flags))
			return;

		dump_stack();
		/*
		 * There is no need to withdraw when the superblock hasn't been
		 * fully initialized, yet.
		 */
		if (!(sdp->sd_vfs->s_flags & SB_BORN))
			return;
		fs_err(sdp, "about to withdraw this file system\n");
		schedule_work(&sdp->sd_withdraw_work);
    ...
}

CPU0 (mount / remount)            CPU1 (kthread / workqueue / sysfs)
vfs_get_tree()
  ...
  gfs2_fill_super()
    gfs2_make_fs_rw()
      set_bit(SDF_JOURNAL_LIVE)
                                  gfs2_withdraw()
                                    test_and_set_bit(SDF_WITHDRAWN)
                                    if (!(s_flags & SB_BORN))
                                      return;
  sb->s_flags |= SB_BORN

gfs2_reconfigure()
  gfs2_make_fs_ro()
    gfs2_log_flush()
      if (gfs2_withdrawn(sdp))
        return;
    wait_on_bit(..., SDF_JOURNAL_LIVE, ...)
      <-- sleeps forever holding sb->s_umount

Because SDF_WITHDRAWN is already set, later calls to gfs2_withdraw() also
return early, so do_withdraw() never runs to clear SDF_JOURNAL_LIVE.  A
subsequent read-only remount bails out of gfs2_log_flush() and blocks
forever in wait_on_bit() with sb->s_umount held in write mode.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113-work-fs-sb_rdonly-v3-0-0be92bb73709@kernel.org?part=27

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2026-11-14 12:03 UTC|newest]

Thread overview: 118+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 11:58 [PATCH v3 00/33] fs: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-11-13 11:58 ` Christian Brauner
2026-11-13 11:58 ` [PATCH v3 01/33] jfs: free uncommitted anonymous tlocks when evicting an inode Christian Brauner
2026-11-13 11:58   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:58 ` [PATCH v3 02/33] jfs: use jfs_symlink_inode_operations in jfs_iget() Christian Brauner
2026-11-13 11:58   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:58 ` [PATCH v3 03/33] ecryptfs: don't leak the inode when a lookup can't open the lower file Christian Brauner
2026-11-13 11:58   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 04/33] ecryptfs: fall back to a read-only " Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 05/33] fs: add a generic emergency read-only state Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-13 14:53   ` Jan Kara
2026-11-13 14:53     ` Jan Kara
2026-11-14 12:03   ` sashiko-bot
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 06/33] ext2: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-13 14:54   ` Jan Kara
2026-11-13 14:54     ` Jan Kara
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 07/33] jfs: " Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 08/33] nilfs2: " Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 09/33] fat: " Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 10/33] exfat: keep the current mount options on remount Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 11/33] exfat: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 12/33] exfat: use the generic emergency read-only state Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 13/33] hfs: don't set SB_RDONLY after MDB write errors Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 14/33] hfs: use the generic emergency read-only state Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 15/33] hfsplus: don't set SB_RDONLY when creating the attributes tree Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 16/33] affs: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 17/33] ufs: " Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 18/33] hpfs: " Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 19/33] ntfs: " Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 20/33] ntfs: use the generic emergency read-only state Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 21/33] ocfs2: keep the current mount options on remount Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 22/33] ocfs2: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 23/33] zonefs: don't set SB_RDONLY after I/O errors Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 24/33] zonefs: use the generic emergency read-only state Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 25/33] btrfs: check BTRFS_FS_STATE_RO instead of SB_RDONLY at runtime Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 26/33] btrfs: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 27/33] gfs2: wait for a pending withdraw before remounting read-only Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot [this message]
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 28/33] gfs2: don't set SB_RDONLY on withdraw Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 29/33] efivarfs: stop using SB_RDONLY for read-only efivar ops Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 30/33] ubifs: don't set SB_RDONLY after errors Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14  2:17   ` Zhihao Cheng
2026-11-14  2:17     ` Zhihao Cheng
2026-11-14 12:03   ` sashiko-bot
2026-11-14 12:03     ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 31/33] ext4: allow remounting read-only in the emergency state Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 32/33] ext4: use the generic emergency read-only state Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot
2026-11-13 11:59 ` [PATCH v3 33/33] xfs: allow remounting read-only after a shutdown Christian Brauner
2026-11-13 11:59   ` Christian Brauner
2026-11-14 12:03   ` sashiko-bot

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=sashiko-outbox-214478@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=brauner@kernel.org \
    --cc=dsterba@suse.cz \
    --cc=jack@suse.com \
    --cc=jlbec@evilplan.org \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mark@fasheh.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.