Re: [PATCH v2] btrfs: use IOMAP_DIO_BOUNCE flag instead of falling back to buffered IO

[Christoph Hellwig <hch@infradead.org>]

On Mon, May 25, 2026 at 06:44:48PM +0930, Qu Wenruo wrote:
> Currently btrfs avoids the deadlock by disabling page fault for the @from
> iov_iter.
> 
> But that iov_iter->nofault is not respected during
> bio_iov_iter_bounce_write() -> copy_from_iter(), thus we will hit a deadlock
> at exactly the situation described in the comment just before
> btrfs_dio_write() call.

Yeah.  We could try to propagate it, but ...

> I tried to check how XFS handles this, and XFS seems to go a completely
> different way using different flags for xfs_ilock().

Note that the flag is just messaging.  The important part is that XFS
uses a different lock for protecting the internal state in the inode
like the extent mapping (xfs_inode.i_lock) vs the highlevel VFS lock
protecting I/O (inode.i_rwsem), which is really important to avoid
all kinds of locking pitfalls.  I thought btrfs was doing the same,
but maybe this is some other lock you are seeing the recursion on?

Sorting out the locking is good way to avoid these problems and also
integrate better with common VFS helpers and/or iomap.

> Or we should add some extra checks inside btrfs? E.g. if we found out that
> the folio we're reading belongs to a direct write, instead of waiting for
> the OE to finish, returning -EFAULT?

Oh, this isn't actually a lock, but the ordered_extent wait?  My memory
is a little fuzzy, but I think this is the same problem with the
ordered_extent semantics that is also causing so many other problems:

btrfs completes the pagecache level writeback (that is clearing the
folio writeback bit) before the ordered_extent has completed and thus
the metadata has been recorded.  Which breaks the assumptions of all
the common VFS code, and requires reads into the pagecache to lock
the extent.  If you'd manage to fix the writeback code to only clear
the folio writeback bit once all metadata is recorded in the right place
all this would go away.  I.e. call btrfs_folio_clear_writeback only
from the finish ordered extent context and not directly from
end_bbio_data_write.  I tried this a long time ago and was running
into problems, but you cleaned up a lot of the mess in this area
since, so it might be easier now.