From: sashiko-bot@kernel.org
To: "Jiale Yao" <yaojiale02@163.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH 2/3] ntfs: drain in-flight DIO before buffered write fallback
Date: Thu, 24 Sep 2026 11:21:04 +0000 [thread overview]
Message-ID: <20260924112104.7FFA41F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924110544.601390-3-yaojiale02@163.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] fs: ntfs: sleeping in IOCB_NOWAIT path via inode_dio_wait()
--
commit 8795f10ca6e1ad5705cf4c0e2062d0271399c2d2
Author: Jiale Yao <yaojiale02@163.com>
ntfs: drain in-flight DIO before buffered write fallback
This commit adds a wait for in-flight direct I/O before falling back
to buffered I/O in the NTFS write path. This prevents data corruption
caused by concurrent direct and buffered I/O dirtying the same pages.
Link: https://lore.kernel.org/r/20260629113827.4074335-3-libaokun@linux.alibaba.com
> diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c
> index 8164326b7812a..329871bb476f4 100644
> --- a/fs/ntfs/file.c
> +++ b/fs/ntfs/file.c
> @@ -526,6 +526,13 @@ static ssize_t ntfs_dio_write_iter(struct kiocb *iocb, struct iov_iter *from)
>
> offset = iocb->ki_pos;
> iocb->ki_flags &= ~IOCB_DIRECT;
> +
> + /*
> + * Prevent concurrent direct I/O and buffered I/O to the same file
> + * range. Wait for in-flight DIO to finish before dirtying pages.
> + */
> + inode_dio_wait(file_inode(iocb->ki_filp));
> +
[Severity: Medium]
Does this unconditional wait violate the non-blocking semantics of IOCB_NOWAIT?
If an asynchronous direct write with IOCB_NOWAIT is issued, and iomap_dio_rw()
returns -ENOTBLK (for example, if kiocb_invalidate_pages() fails with -EBUSY
due to a concurrently instantiated page), the code enters this buffered I/O
fallback path in ntfs_dio_write_iter().
Calling inode_dio_wait() here will unconditionally sleep if there are other
concurrent direct I/Os in flight on the inode.
Could this stall async I/O worker threads (such as those in io_uring) and
cause unexpected latency spikes when it should instead return -EAGAIN?
> written = iomap_file_buffered_write(iocb, from,
> &ntfs_write_iomap_ops, &ntfs_iomap_folio_ops,
> NULL);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260924110544.601390-1-yaojiale02@163.com?part=2
next prev parent reply other threads:[~2026-09-24 11:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 11:05 [PATCH 0/3] fs: drain in-flight DIO before buffered write fallback Jiale Yao
2026-09-24 11:05 ` [PATCH 1/3] ext2: " Jiale Yao
2026-09-24 11:13 ` sashiko-bot
2026-09-24 11:05 ` [PATCH 2/3] ntfs: " Jiale Yao
2026-09-24 11:21 ` sashiko-bot [this message]
2026-09-24 12:04 ` liubaolin
2026-09-24 12:20 ` jiale yao
2026-09-26 7:29 ` jiale yao
2026-09-24 11:05 ` [PATCH 3/3] exfat: " Jiale Yao
2026-09-24 11:15 ` 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=20260924112104.7FFA41F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tytso@mit.edu \
--cc=yaojiale02@163.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 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.