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,
	"Viacheslav Dubeyko" <slava@dubeyko.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 11/34] hfs: don't set SB_RDONLY after MDB write errors
Date: Fri, 30 Oct 2026 16:09:57 +0000	[thread overview]
Message-ID: <sashiko-outbox-191230@kernel.org> (raw)
In-Reply-To: <20261029-work-fs-sb_rdonly-v2-11-2f44f64f0b66@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] hfs: hfs_file_truncate() early return leaves in-memory inode sizes inconsistent
--

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

hfs: don't set SB_RDONLY after MDB write errors

Instead of setting SB_RDONLY without holding s_umount when an MDB write fails,
this commit records the error in a new HFS_FLG_EMERGENCY_RO flag and rejects
subsequent filesystem modifications with EROFS.

> diff --git a/fs/hfs/extent.c b/fs/hfs/extent.c
> index 26357086517fc..dacf7ce1ffe4a 100644
> --- a/fs/hfs/extent.c
> +++ b/fs/hfs/extent.c

[ ... ]

> @@ -491,6 +494,8 @@ void hfs_file_truncate(struct inode *inode)
>  	hfs_dbg("ino %llu, phys_size %llu -> i_size %llu\n",
>  		inode->i_ino, (long long)HFS_I(inode)->phys_size,
>  		inode->i_size);
> +	if (unlikely(hfs_emergency_ro(sb)))
> +		return;
>  	if (inode->i_size > HFS_I(inode)->phys_size) {
>  		struct address_space *mapping = inode->i_mapping;
>  		void *fsdata = NULL;

[Severity: Medium]
Can returning at the top of hfs_file_truncate() in fs/hfs/extent.c leave
in-memory inode size metadata inconsistent when HFS_FLG_EMERGENCY_RO (or
SB_STATE_EMERGENCY_RO in the follow-up commit "hfs: use the generic
emergency read-only state") is set concurrently by the mdb_work worker or
sync_fs()?

First, in the expanding truncate path via hfs_inode_setattr() in
fs/hfs/inode.c (or notify_change() in the follow-up commit):

    if ((attr->ia_valid & ATTR_SIZE) &&
        attr->ia_size != i_size_read(inode)) {
            inode_dio_wait(inode);

            error = inode_newsize_ok(inode, attr->ia_size);
            if (error)
                    return error;

            truncate_setsize(inode, attr->ia_size);
            hfs_file_truncate(inode);

If HFS_FLG_EMERGENCY_RO is set after the initial read-only check (for
example, while waiting in inode_dio_wait()), truncate_setsize() updates
inode->i_size and then hfs_file_truncate() returns early before reaching
the expansion block:

    if (inode->i_size > HFS_I(inode)->phys_size) {
            ...
            res = hfs_write_begin(NULL, mapping, size + 1, 0, &folio,
                            &fsdata);
            ...
            if (res)
                    inode->i_size = HFS_I(inode)->phys_size;
            return;
    }

Without the early return, hfs_write_begin() fails with -EROFS and reverts
inode->i_size back to HFS_I(inode)->phys_size. With the early return,
hfs_inode_setattr() succeeds with inode->i_size larger than
HFS_I(inode)->phys_size and HFS_I(inode)->fs_blocks, causing subsequent
buffered reads via hfs_read_folio() -> block_read_full_folio() ->
hfs_get_block() to see unallocated blocks and return zero-filled pages up
to the new inode->i_size.

Second, when an extending write in hfs_write_begin() or hfs_direct_IO()
allocates some blocks via hfs_get_block() (incrementing
HFS_I(inode)->phys_size, HFS_I(inode)->fs_blocks, and inode->i_bytes) and
then hits -EROFS on a subsequent block after HFS_FLG_EMERGENCY_RO is set,
error cleanup calls hfs_write_failed():

    static void hfs_write_failed(struct address_space *mapping, loff_t to)
    {
            struct inode *inode = mapping->host;

            if (to > inode->i_size) {
                    truncate_pagecache(inode, inode->i_size);
                    hfs_file_truncate(inode);
            }
    }

Returning early at the top of hfs_file_truncate() skips the out: label
adjustments as well, leaving HFS_I(inode)->phys_size,
HFS_I(inode)->fs_blocks, and the inode byte count inflated past
inode->i_size.

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

______________________________________________________
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,
	"Viacheslav Dubeyko" <slava@dubeyko.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 11/34] hfs: don't set SB_RDONLY after MDB write errors
Date: Fri, 30 Oct 2026 16:09:57 +0000	[thread overview]
Message-ID: <sashiko-outbox-191230@kernel.org> (raw)
In-Reply-To: <20261029-work-fs-sb_rdonly-v2-11-2f44f64f0b66@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] hfs: hfs_file_truncate() early return leaves in-memory inode sizes inconsistent
--

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

hfs: don't set SB_RDONLY after MDB write errors

Instead of setting SB_RDONLY without holding s_umount when an MDB write fails,
this commit records the error in a new HFS_FLG_EMERGENCY_RO flag and rejects
subsequent filesystem modifications with EROFS.

> diff --git a/fs/hfs/extent.c b/fs/hfs/extent.c
> index 26357086517fc..dacf7ce1ffe4a 100644
> --- a/fs/hfs/extent.c
> +++ b/fs/hfs/extent.c

[ ... ]

> @@ -491,6 +494,8 @@ void hfs_file_truncate(struct inode *inode)
>  	hfs_dbg("ino %llu, phys_size %llu -> i_size %llu\n",
>  		inode->i_ino, (long long)HFS_I(inode)->phys_size,
>  		inode->i_size);
> +	if (unlikely(hfs_emergency_ro(sb)))
> +		return;
>  	if (inode->i_size > HFS_I(inode)->phys_size) {
>  		struct address_space *mapping = inode->i_mapping;
>  		void *fsdata = NULL;

[Severity: Medium]
Can returning at the top of hfs_file_truncate() in fs/hfs/extent.c leave
in-memory inode size metadata inconsistent when HFS_FLG_EMERGENCY_RO (or
SB_STATE_EMERGENCY_RO in the follow-up commit "hfs: use the generic
emergency read-only state") is set concurrently by the mdb_work worker or
sync_fs()?

First, in the expanding truncate path via hfs_inode_setattr() in
fs/hfs/inode.c (or notify_change() in the follow-up commit):

    if ((attr->ia_valid & ATTR_SIZE) &&
        attr->ia_size != i_size_read(inode)) {
            inode_dio_wait(inode);

            error = inode_newsize_ok(inode, attr->ia_size);
            if (error)
                    return error;

            truncate_setsize(inode, attr->ia_size);
            hfs_file_truncate(inode);

If HFS_FLG_EMERGENCY_RO is set after the initial read-only check (for
example, while waiting in inode_dio_wait()), truncate_setsize() updates
inode->i_size and then hfs_file_truncate() returns early before reaching
the expansion block:

    if (inode->i_size > HFS_I(inode)->phys_size) {
            ...
            res = hfs_write_begin(NULL, mapping, size + 1, 0, &folio,
                            &fsdata);
            ...
            if (res)
                    inode->i_size = HFS_I(inode)->phys_size;
            return;
    }

Without the early return, hfs_write_begin() fails with -EROFS and reverts
inode->i_size back to HFS_I(inode)->phys_size. With the early return,
hfs_inode_setattr() succeeds with inode->i_size larger than
HFS_I(inode)->phys_size and HFS_I(inode)->fs_blocks, causing subsequent
buffered reads via hfs_read_folio() -> block_read_full_folio() ->
hfs_get_block() to see unallocated blocks and return zero-filled pages up
to the new inode->i_size.

Second, when an extending write in hfs_write_begin() or hfs_direct_IO()
allocates some blocks via hfs_get_block() (incrementing
HFS_I(inode)->phys_size, HFS_I(inode)->fs_blocks, and inode->i_bytes) and
then hits -EROFS on a subsequent block after HFS_FLG_EMERGENCY_RO is set,
error cleanup calls hfs_write_failed():

    static void hfs_write_failed(struct address_space *mapping, loff_t to)
    {
            struct inode *inode = mapping->host;

            if (to > inode->i_size) {
                    truncate_pagecache(inode, inode->i_size);
                    hfs_file_truncate(inode);
            }
    }

Returning early at the top of hfs_file_truncate() skips the out: label
adjustments as well, leaving HFS_I(inode)->phys_size,
HFS_I(inode)->fs_blocks, and the inode byte count inflated past
inode->i_size.

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


  reply	other threads:[~2026-10-30 16:10 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
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 [this message]
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-191230@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=slava@dubeyko.com \
    --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.