From: Hongling Zeng <zhongling0719@126.com>
To: Namjae Jeon <linkinjeon@kernel.org>,
Hongling Zeng <zenghongling@kylinos.cn>
Cc: hyc.lee@gmail.com, ntfs@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] ntfs: fix lost volume flag updates in set/clear helpers
Date: Wed, 02 Sep 2026 14:12:09 +0800 [thread overview]
Message-ID: <6A97BE39.8090301@126.com> (raw)
In-Reply-To: <CAKYAXd8dotRFBu18HOZGr6AJn4EfTwj=ZtfwheCTy0H7tbLfFA@mail.gmail.com>
在 2026年09月02日 09:06, Namjae Jeon 写道:
> On Tue, Sep 1, 2026 at 11:46 AM Hongling Zeng <zenghongling@kylinos.cn> wrote:
>> ntfs_set_volume_flags() and ntfs_clear_volume_flags() both read
>> vol->vol_flags outside any lock to compute the new value before handing
>> it to ntfs_write_volume_flags(), which only takes ni->mrec_lock around
>> the actual write. The read-modify-write is therefore not atomic, and two
>> concurrent callers can lose an update: ntfs_sync_fs() may derive a
>> "clean" value from vol->vol_flags while a writer concurrently records an
>> error and sets VOLUME_IS_DIRTY; the locked write then silently
>> overwrites the freshly-set dirty bit. The on-disk volume looks clean
>> despite the recorded errors, so chkdsk will not run on the next mount
>> and corrupted metadata can persist.
> This patch description explicitly identifies ntfs_sync_fs() as the
> problematic caller, but there still remains a racy issue after
> applying this patch.
>
> static int ntfs_sync_fs(struct super_block *sb, int wait)
> {
> ...
> if (!NVolErrors(vol) &&
> ntfs_clear_volume_flags(vol, VOLUME_IS_DIRTY)) {
> ntfs_warning(sb, "Failed to clear dirty bit in volume
> information flags. Run chkdsk.");
> err = -EIO;
> }
>
> Sync thread Writer thread
> ----------- -------------
> 1. NVolErrors() == false
> 2. Set VOLUME_IS_DIRTY
> under mrec_lock
> 3. NVolSetErrors()
> 4. ntfs_clear_volume_flags()
>
> The volume can be left marked clean on disk despite the recorded
> error... Can you update this patch to fix this issue as well?
|You're right. My current patch fixes the lost update in the set/clear
helpers, but ntfs_sync_fs() still has a TOCTOU race between NVolErrors()
and clearing VOLUME_IS_DIRTY.
I'll update the patch to make the error check and dirty-bit clear happen
under the same mrec_lock, so the sync path won't clear the bit after a
concurrent error update.
Thanks |
prev parent reply other threads:[~2026-09-02 6:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 2:45 Hongling Zeng
2026-09-01 3:27 ` liubaolin
2026-09-02 1:06 ` Namjae Jeon
2026-09-02 6:12 ` Hongling Zeng [this message]
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=6A97BE39.8090301@126.com \
--to=zhongling0719@126.com \
--cc=hyc.lee@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntfs@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=zenghongling@kylinos.cn \
/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®