Re: [PATCH 3/5] xfs: drain in-flight DIO before buffered writes

[Dave Chinner <dgc@kernel.org>]

On Sun, Oct 25, 2026 at 08:41:12PM +0800, Jiale Yao wrote:
> XFS_IOLOCK_EXCL prevents new direct I/O submissions, but asynchronous
> direct writes submitted while the lock was shared can remain active after
> their submitting threads release the lock. A buffered write can then dirty
> page cache before direct I/O completion performs post-write invalidation.
> 
> Wait for active DIO after acquiring XFS_IOLOCK_EXCL and before buffered
> write checks can modify page cache. Return -EAGAIN instead of waiting for
> an IOCB_NOWAIT request.
> 
> Fixes: acdda3aae146 ("xfs: use iomap_dio_rw")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiale Yao <yaojiale02@163.com>
> ---
>  fs/xfs/xfs_file.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)

This doesn't fix the page cache dirtying race condition. Write to
the file with mmap() instead of write() and the same thing happens.
Because ->page-mkwrite() doesn't use the IOLOCK, it can't be
serialised against DIO submission or in flight DIO.

Regardless, overlapping buffered and direct writes to the same file
indicate an application bug that needs fixing because the result of
such IO patterns is not deterministic (even with this "fix").

Sometimes the DIO write will win, sometimes the buffered write will
win. Either way, one of the application writes gets lost and so we
still have data corruption from an application perspective...

IOWs, all this patch does is shut up the warning that tells us that
the application is doing stupid things that could result in data
corruption.

-Dave.
-- 
Dave Chinner
dgc@kernel.org