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,
	"Karl Mehltretter" <kmehltretter@gmail.com>,
	"Ryusuke Konishi" <konishi.ryusuke@gmail.com>,
	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 v2 06/34] nilfs2: don't set SB_RDONLY after filesystem errors
Date: Fri, 30 Oct 2026 16:09:52 +0000	[thread overview]
Message-ID: <sashiko-outbox-191225@kernel.org> (raw)
In-Reply-To: <20261029-work-fs-sb_rdonly-v2-6-2f44f64f0b66@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] nilfs2: nilfs_reconfigure() and nilfs_get_tree() bypass sb_emergency_ro()
--

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

nilfs2: don't set SB_RDONLY after filesystem errors

This commit replaces setting SB_RDONLY in __nilfs_error() with
sb_set_emergency_ro() and introduces nilfs_sb_rdonly() to guard write paths
after filesystem errors without taking s_umount.

Link: https://lore.kernel.org/r/20260903060855.4610-1-kmehltretter@gmail.com

> diff --git a/fs/nilfs2/super.c b/fs/nilfs2/super.c
> index 2e3b591c117c9..edb7d379ecbdf 100644
> --- a/fs/nilfs2/super.c
> +++ b/fs/nilfs2/super.c
> @@ -137,12 +137,13 @@ void __nilfs_error(struct super_block *sb, const char *function,
>  
>  	va_end(args);
>  
> -	if (!sb_rdonly(sb)) {
> +	if (!nilfs_sb_rdonly(sb)) {
>  		nilfs_set_error(sb);
>  
>  		if (nilfs_test_opt(nilfs, ERRORS_RO)) {
>  			printk(KERN_CRIT "Remounting filesystem read-only\n");
> -			sb->s_flags |= SB_RDONLY;
> +			/* SB_RDONLY needs s_umount, see sb_set_emergency_ro(). */
> +			sb_set_emergency_ro(sb);
>  		}
>  	}

[ ... ]

> @@ -1141,6 +1146,10 @@ static int nilfs_reconfigure(struct fs_context *fc)
>  	if (fc->sb_flags & SB_RDONLY) {
>  		sb->s_flags |= SB_RDONLY;
>  
> +		/* After an error nothing may be written, just go read-only. */
> +		if (sb_emergency_ro(sb))
> +			goto out;
> +
>  		/*
>  		 * Remounting a valid RW partition RDONLY, so set
>  		 * the RDONLY flag and then mark the partition as valid again.
> @@ -1152,6 +1161,12 @@ static int nilfs_reconfigure(struct fs_context *fc)
>  		__u64 features;
>  		struct nilfs_root *root;
>  
> +		/* The VFS doesn't refuse this when nilfs_get_tree() calls us. */
> +		if (sb_emergency_ro(sb)) {
> +			err = -EROFS;
> +			goto ignore_opts;
> +		}
> +

[Severity: Medium]
Can this sb_emergency_ro(sb) check in the else branch of nilfs_reconfigure()
be bypassed after an error on a read-write mount?

When __nilfs_error() calls sb_set_emergency_ro(sb) on a read-write mount,
SB_RDONLY is not set in sb->s_flags, so sb_rdonly(sb) remains false.

In nilfs_reconfigure(), right before the if (fc->sb_flags & SB_RDONLY) block:

	if ((bool)(fc->sb_flags & SB_RDONLY) == sb_rdonly(sb))
		goto out;

When a read-write mount or remount is requested (!(fc->sb_flags & SB_RDONLY))
on a superblock where sb_emergency_ro(sb) is true and sb_rdonly(sb) is still
false (for example, via nilfs_get_tree() -> nilfs_reconfigure() when the
superblock was kept alive by a snapshot after the corrupted read-write mount
was unmounted, or via reconfigure_super() -> nilfs_reconfigure() on a direct
remount,rw without an intermediate remount,ro), this comparison evaluates
false == false and jumps straight to out, overwriting nilfs->ns_mount_opt and
returning 0 instead of -EROFS.

Also, in nilfs_get_tree(), when nilfs_tree_is_busy(s->s_root) is true:

	} else if (!ctx->cno) {
		if (nilfs_tree_is_busy(s->s_root)) {
			if ((fc->sb_flags ^ s->s_flags) & SB_RDONLY) {
				nilfs_err(s,
					  "the device already has a %s mount.",
					  sb_rdonly(s) ? "read-only" : "read/write");
				err = -EBUSY;
				goto failed_super;
			}

Because s->s_flags does not have SB_RDONLY set after sb_set_emergency_ro(s),
doesn't this treat the emergency read-only superblock as read/write, rejecting
a secondary read-only mount with -EBUSY while allowing a secondary read-write
mount?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029-work-fs-sb_rdonly-v2-0-2f44f64f0b66@kernel.org?part=6

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

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,
	"Karl Mehltretter" <kmehltretter@gmail.com>,
	"Ryusuke Konishi" <konishi.ryusuke@gmail.com>,
	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 v2 06/34] nilfs2: don't set SB_RDONLY after filesystem errors
Date: Fri, 30 Oct 2026 16:09:52 +0000	[thread overview]
Message-ID: <sashiko-outbox-191225@kernel.org> (raw)
In-Reply-To: <20261029-work-fs-sb_rdonly-v2-6-2f44f64f0b66@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] nilfs2: nilfs_reconfigure() and nilfs_get_tree() bypass sb_emergency_ro()
--

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

nilfs2: don't set SB_RDONLY after filesystem errors

This commit replaces setting SB_RDONLY in __nilfs_error() with
sb_set_emergency_ro() and introduces nilfs_sb_rdonly() to guard write paths
after filesystem errors without taking s_umount.

Link: https://lore.kernel.org/r/20260903060855.4610-1-kmehltretter@gmail.com

> diff --git a/fs/nilfs2/super.c b/fs/nilfs2/super.c
> index 2e3b591c117c9..edb7d379ecbdf 100644
> --- a/fs/nilfs2/super.c
> +++ b/fs/nilfs2/super.c
> @@ -137,12 +137,13 @@ void __nilfs_error(struct super_block *sb, const char *function,
>  
>  	va_end(args);
>  
> -	if (!sb_rdonly(sb)) {
> +	if (!nilfs_sb_rdonly(sb)) {
>  		nilfs_set_error(sb);
>  
>  		if (nilfs_test_opt(nilfs, ERRORS_RO)) {
>  			printk(KERN_CRIT "Remounting filesystem read-only\n");
> -			sb->s_flags |= SB_RDONLY;
> +			/* SB_RDONLY needs s_umount, see sb_set_emergency_ro(). */
> +			sb_set_emergency_ro(sb);
>  		}
>  	}

[ ... ]

> @@ -1141,6 +1146,10 @@ static int nilfs_reconfigure(struct fs_context *fc)
>  	if (fc->sb_flags & SB_RDONLY) {
>  		sb->s_flags |= SB_RDONLY;
>  
> +		/* After an error nothing may be written, just go read-only. */
> +		if (sb_emergency_ro(sb))
> +			goto out;
> +
>  		/*
>  		 * Remounting a valid RW partition RDONLY, so set
>  		 * the RDONLY flag and then mark the partition as valid again.
> @@ -1152,6 +1161,12 @@ static int nilfs_reconfigure(struct fs_context *fc)
>  		__u64 features;
>  		struct nilfs_root *root;
>  
> +		/* The VFS doesn't refuse this when nilfs_get_tree() calls us. */
> +		if (sb_emergency_ro(sb)) {
> +			err = -EROFS;
> +			goto ignore_opts;
> +		}
> +

[Severity: Medium]
Can this sb_emergency_ro(sb) check in the else branch of nilfs_reconfigure()
be bypassed after an error on a read-write mount?

When __nilfs_error() calls sb_set_emergency_ro(sb) on a read-write mount,
SB_RDONLY is not set in sb->s_flags, so sb_rdonly(sb) remains false.

In nilfs_reconfigure(), right before the if (fc->sb_flags & SB_RDONLY) block:

	if ((bool)(fc->sb_flags & SB_RDONLY) == sb_rdonly(sb))
		goto out;

When a read-write mount or remount is requested (!(fc->sb_flags & SB_RDONLY))
on a superblock where sb_emergency_ro(sb) is true and sb_rdonly(sb) is still
false (for example, via nilfs_get_tree() -> nilfs_reconfigure() when the
superblock was kept alive by a snapshot after the corrupted read-write mount
was unmounted, or via reconfigure_super() -> nilfs_reconfigure() on a direct
remount,rw without an intermediate remount,ro), this comparison evaluates
false == false and jumps straight to out, overwriting nilfs->ns_mount_opt and
returning 0 instead of -EROFS.

Also, in nilfs_get_tree(), when nilfs_tree_is_busy(s->s_root) is true:

	} else if (!ctx->cno) {
		if (nilfs_tree_is_busy(s->s_root)) {
			if ((fc->sb_flags ^ s->s_flags) & SB_RDONLY) {
				nilfs_err(s,
					  "the device already has a %s mount.",
					  sb_rdonly(s) ? "read-only" : "read/write");
				err = -EBUSY;
				goto failed_super;
			}

Because s->s_flags does not have SB_RDONLY set after sb_set_emergency_ro(s),
doesn't this treat the emergency read-only superblock as read/write, rejecting
a secondary read-only mount with -EBUSY while allowing a secondary read-write
mount?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029-work-fs-sb_rdonly-v2-0-2f44f64f0b66@kernel.org?part=6


  reply	other threads:[~2026-10-30 16:09 UTC|newest]

Thread overview: 121+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 16:06 [PATCH v2 00/34] fs: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-10-29 16:06 ` Christian Brauner
2026-10-29 16:06 ` [PATCH v2 01/34] ecryptfs: don't leak the inode when a lookup can't open the lower file Christian Brauner
2026-10-29 16:06   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-29 16:06 ` [PATCH v2 02/34] ecryptfs: fall back to a read-only " Christian Brauner
2026-10-29 16:06   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-30 16:09     ` sashiko-bot
2026-10-29 16:06 ` [PATCH v2 03/34] fs: add a generic emergency read-only state Christian Brauner
2026-10-29 16:06   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-29 16:06 ` [PATCH v2 04/34] ext2: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-10-29 16:06   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-29 16:06 ` [PATCH v2 05/34] jfs: " Christian Brauner
2026-10-29 16:06   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-30 16:09     ` sashiko-bot
2026-10-29 16:06 ` [PATCH v2 06/34] nilfs2: " Christian Brauner
2026-10-29 16:06   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot [this message]
2026-10-30 16:09     ` sashiko-bot
2026-10-29 16:06 ` [PATCH v2 07/34] fat: " Christian Brauner
2026-10-29 16:06   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-30 16:09     ` sashiko-bot
2026-10-29 16:06 ` [PATCH v2 08/34] exfat: keep the current mount options on remount Christian Brauner
2026-10-29 16:06   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 09/34] exfat: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-30 16:09     ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 10/34] exfat: use the generic emergency read-only state Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 11/34] hfs: don't set SB_RDONLY after MDB write errors Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-30 16:09     ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 12/34] hfs: use the generic emergency read-only state Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 13/34] hfsplus: don't set SB_RDONLY when creating the attributes tree Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:09   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 14/34] affs: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 15/34] ufs: " Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 16/34] hpfs: " Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-30 16:10     ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 17/34] ntfs: " Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-30 16:10     ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 18/34] ntfs: use the generic emergency read-only state Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 19/34] ocfs2: keep the current mount options on remount Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30  2:58   ` Joseph Qi
2026-10-30  2:58     ` Joseph Qi
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 20/34] ocfs2: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30  3:01   ` Joseph Qi
2026-10-30  3:01     ` Joseph Qi
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 21/34] zonefs: don't set SB_RDONLY after I/O errors Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 22/34] zonefs: use the generic emergency read-only state Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 23/34] btrfs: check BTRFS_FS_STATE_RO instead of SB_RDONLY at runtime Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 24/34] btrfs: don't set SB_RDONLY after filesystem errors Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 25/34] gfs2: wait for a pending withdraw before remounting read-only Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-30 16:10     ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 26/34] gfs2: don't set SB_RDONLY on withdraw Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-30 16:10     ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 27/34] efivarfs: stop using SB_RDONLY for read-only efivar ops Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 28/34] ubifs: don't set SB_RDONLY after errors Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30  3:42   ` Zhihao Cheng
2026-10-30  3:42     ` Zhihao Cheng
2026-10-30 16:10   ` sashiko-bot
2026-10-30 16:10     ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 29/34] selftests/filesystems: test filesystem errors while frozen Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 30/34] ext4: allow remounting read-only in the emergency state Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 31/34] ext4: use the generic emergency read-only state Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 32/34] selftests/filesystems: test ext4 remounts in the emergency state Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 33/34] xfs: allow remounting read-only after a shutdown Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` sashiko-bot
2026-10-29 16:07 ` [PATCH v2 34/34] selftests/filesystems: test xfs remounts " Christian Brauner
2026-10-29 16:07   ` Christian Brauner
2026-10-30 16:10   ` 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-191225@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=kmehltretter@gmail.com \
    --cc=konishi.ryusuke@gmail.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.