From: liubaolin <liubaolin12138@163.com>
To: Hongling Zeng <zenghongling@kylinos.cn>,
linkinjeon@kernel.org, hyc.lee@gmail.com
Cc: ntfs@lists.linux.dev, linux-kernel@vger.kernel.org,
zhongling0719@126.com, Baolin Liu <liubaolin@kylinos.cn>,
stable@vger.kernel.org
Subject: Re: [PATCH v13 5/7] ntfs: do not clear the volume dirty bit during sync
Date: Thu, 17 Sep 2026 05:18:12 +0800 [thread overview]
Message-ID: <2cc9b583-8966-454e-9e5e-48e992ca6070@163.com> (raw)
In-Reply-To: <20260915083252.812126-6-zenghongling@kylinos.cn>
在 2026/9/15 16:32, Hongling Zeng 写道:
> ntfs_sync_fs() clears VOLUME_IS_DIRTY while the volume is still mounted
> read-write, so a sync running concurrently with an in-flight metadata
> modification can clear and persist a bit that was just set: the
> modification then lands on a volume that is clean on disk, and a crash
> does not run chkdsk.
>
> Stop clearing the bit in ntfs_sync_fs() and leave the clearing to the
> remount-to-read-only path, which the VFS reaches only after
> sb_prepare_remount_readonly() has drained in-flight writers, and to
> ntfs_put_super(), which runs after evict_inodes() on a quiesced
> filesystem. A mounted read-write volume now keeps the dirty bit until
> it is dismounted cleanly, which matches the NTFS semantics; the cost is
> a needless chkdsk if the machine crashes between a sync and the unmount.
>
> A recorded error state is still persisted right away when the
> filesystem is synced: with NVolErrors() set,
> ntfs_sync_volume_dirty_state() can only set the bit, never clear it,
> so it cannot lose a modification the way the old unconditional call
> did. This keeps the error report from being lost to a crash on a
> volume that has seen no modification; an error recorded after the
> last sync is still only persisted at the next quiescent transition.
>
> sync_blockdev() and blkdev_issue_flush() are both called and the first
> error is returned, so a writeback failure neither hides a flush failure
> nor skips it.
>
> A RWF_NOWAIT write still blocks in the marking when the volume looks
> clean, as it already did on the base; a non-blocking marking is
> follow-up work.
>
> Reported-by: Baolin Liu <liubaolin@kylinos.cn>
> Cc: stable@vger.kernel.org
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> ---
> fs/ntfs/file.c | 7 ++++---
> fs/ntfs/super.c | 31 ++++++++++++++++++++++++-------
> 2 files changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c
> index cfc7b36b7dff..99a2c7a5cf81 100644
> --- a/fs/ntfs/file.c
> +++ b/fs/ntfs/file.c
> @@ -621,9 +621,10 @@ static ssize_t ntfs_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
>
> /*
> * The volume must be marked dirty before the modification is made,
> - * without an unlocked check of the in-memory flag: ntfs_sync_fs()
> - * can clear the bit concurrently and the modification would then
> - * land on a volume that is clean on disk.
> + * without an unlocked check of the in-memory flag: the dirty bit
> + * is only cleared at the quiescent transitions, under the same
> + * $Volume mrec_lock this call takes, so an unlocked skip could
> + * lose the set to one of them.
> */
> ntfs_set_volume_flags(vol, VOLUME_IS_DIRTY);
>
> diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c
> index 3574c224fe28..463050ae1b0e 100644
> --- a/fs/ntfs/super.c
> +++ b/fs/ntfs/super.c
> @@ -486,8 +486,9 @@ int ntfs_set_volume_flags(struct ntfs_volume *vol, __le16 flags)
> * This is the single point that persists the in-memory error state to disk.
> * The runtime error paths only record NVolErrors() because they run under a
> * variety of ntfs locks the dirty-bit write cannot be taken under (runlist
> - * locks, vol->lcnbmp_lock, vol->mftbmp_lock, mrec_locks); the first
> - * ntfs_sync_fs(), a remount, or the unmount then persists the flag here.
> + * locks, vol->lcnbmp_lock, vol->mftbmp_lock, mrec_locks); a sync of a
> + * volume with recorded errors, a remount to read-only, or the unmount,
> + * then persists the flag here.
> *
> * A hibernated volume is not written from these persistence paths:
> * resuming Windows from a modified image corrupts it, so the dirty bit
> @@ -1955,7 +1956,7 @@ static void ntfs_shutdown(struct super_block *sb)
> static int ntfs_sync_fs(struct super_block *sb, int wait)
> {
> struct ntfs_volume *vol = NTFS_SB(sb);
> - int err = 0;
> + int ret, err = 0;
>
> if (NVolShutdown(vol))
> return -EIO;
> @@ -1963,14 +1964,30 @@ static int ntfs_sync_fs(struct super_block *sb, int wait)
> if (!wait)
> return 0;
>
> - /* If there are some dirty buffers in the bdev inode */
> - if (ntfs_sync_volume_dirty_state(vol)) {
> + /*
> + * The volume dirty bit is deliberately not cleared here: a sync
> + * running concurrently with an in-flight modification could clear
> + * and persist a bit that was just set, leaving the modification
> + * on a volume that is clean on disk. The bit is only cleared at
> + * the quiescent state transitions, remounting read-only and clean
> + * unmount. A recorded error state, however, is persisted right
> + * away so that it is not lost to a crash on a volume that has
> + * seen no modification; with NVolErrors() set this can only set
> + * the bit, never clear it.
> + */
> + if (NVolErrors(vol) &&
> + ntfs_sync_volume_dirty_state(vol)) {
> ntfs_warning(sb, "Failed to sync dirty bit in volume information flags. Run chkdsk.");
> err = -EIO;
> }
> sync_inodes_sb(sb);
> - sync_blockdev(sb->s_bdev);
> - blkdev_issue_flush(sb->s_bdev);
> + ret = sync_blockdev(sb->s_bdev);
> + if (ret && !err)
> + err = ret;
> +
> + ret = blkdev_issue_flush(sb->s_bdev);
> + if (ret && !err)
> + err = ret;
> return err;
> }
>
Looks good to me.
Reviewed-by: Baolin Liu <liubaolin@kylinos.cn>
next prev parent reply other threads:[~2026-09-16 21:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 8:32 [PATCH v13 0/7] ntfs: fix volume flag races and persist the recorded error state Hongling Zeng
2026-09-15 8:32 ` [PATCH v13 1/7] ntfs: fix volume flag update races Hongling Zeng
2026-09-16 20:23 ` liubaolin
2026-09-15 8:32 ` [PATCH v13 2/7] ntfs: set the volume dirty bit unconditionally on metadata changes Hongling Zeng
2026-09-16 20:23 ` liubaolin
2026-09-15 8:32 ` [PATCH v13 3/7] ntfs: sync the volume dirty bit with the recorded error state Hongling Zeng
2026-09-16 20:23 ` liubaolin
2026-09-16 21:17 ` liubaolin
2026-09-15 8:32 ` [PATCH v13 4/7] ntfs: persist the dirty state after the final put_super() commits Hongling Zeng
2026-09-16 21:18 ` liubaolin
2026-09-15 8:32 ` [PATCH v13 5/7] ntfs: do not clear the volume dirty bit during sync Hongling Zeng
2026-09-16 21:18 ` liubaolin [this message]
2026-09-15 8:32 ` [PATCH v13 6/7] ntfs: check the dirty-state commit on remount and unmount Hongling Zeng
2026-09-16 21:18 ` liubaolin
2026-09-15 8:32 ` [PATCH v13 7/7] ntfs: fail remount on sync errors and keep the dirty bit on SB_FORCE Hongling Zeng
2026-09-16 21:18 ` liubaolin
2026-09-16 0:42 ` [PATCH v13 0/7] ntfs: fix volume flag races and persist the recorded error state Hyunchul Lee
2026-09-16 21:36 ` liubaolin
2026-09-16 23:36 ` Namjae Jeon
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=2cc9b583-8966-454e-9e5e-48e992ca6070@163.com \
--to=liubaolin12138@163.com \
--cc=hyc.lee@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liubaolin@kylinos.cn \
--cc=ntfs@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=zenghongling@kylinos.cn \
--cc=zhongling0719@126.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
all inboxes | Powered by JetHome®