Re: [PATCH 1/5] filemap: drain in-flight DIO before buffered writes
From: Christoph Hellwig
Date: Tue Oct 27 2026 - 11:04:15 EST
On Mon, Oct 26, 2026 at 02:31:31PM +0100, Jan Kara wrote:
> > An asynchronous direct write can remain in flight after its submitting
> > thread releases the inode lock. A buffered write can then dirty page
> > cache before the direct write completes its post-I/O invalidation. The
> > invalidation finds dirty pages, reports a possible data corruption, and
> > records -EIO in the mapping error sequence.
>
> Well, when you do stupid things, you get stupid results. We were always
> saying mixing buffered and direct IO in the same file isn't a good idea and
> we try to not screw users too badly but give no promises. This falls into
> that cathegory... So I don't think there's much to fix here.
We have declared it stupid, but people do it anyway. See all the nfsd
patches floating around for in-kernel consumers doing this heavy
and fine grained mixing. So I think we should get this right, and we
should also have test in xfstests to verify the beavior instead of just
shooting into the sky. (related: I only see patches 1 and 5 in my
fsdevel inbox, something is messed up with the series)
> The only
> sensible exception here are simple filesystems which have only simple
> support for direct IO and fallback to buffered IO for the rest. But I think
> we should handle these on a case-by-case basis and either drop the support
> for direct IO altogether or convert them to iomap and properly handle the
> waiting in their .write_iter methods (like e.g. ext2 does it).
That's a bit too easy. There actually is a much better option, which
unfortunately is much more invasive: kill i_dio_wait and move to
non-owner unlocking of i_rwsem from the asynchronous completion handler.
That gets us sane locking behavior without any footguns. I really
regret adding i_dio_wait in hindsight - yes, the PREEMPT_RT folks
hat locks that aren't bound to tasks, but we ended up with a few of
those anyway and thus have the primitives, and file read/write is a
case where they really fit.