All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH v2 0/8] ext4: Add dma-buf read/write support
@ 2026-11-13  7:06 Mengmeng Zhao
  2026-11-13  7:06 ` [RFC PATCH v2 1/8] block: factor out bdev_init_dma_buf_io_ctx() Mengmeng Zhao
                   ` (7 more replies)
  0 siblings, 8 replies; 17+ messages in thread
From: Mengmeng Zhao @ 2026-11-13  7:06 UTC (permalink / raw)
  To: Christoph Hellwig, Anuj Gupta, Nitesh Shetty, Jens Axboe,
	Sumit Semwal, christian.koenig, Philipp Stanner, Dan Williams,
	Matthew Wilcox, Jan Kara, Alexander Viro, Christian Brauner,
	tytso, Andreas Dilger, Baokun Li, Ojaswin Mujoo,
	Ritesh Harjani (IBM), Zhang Yi, asml.silence, Jonathan Corbet,
	Shuah Khan, Randy Dunlap
  Cc: linux-block, linux-kernel, linux-fsdevel, nvdimm, linux-ext4,
	linux-xfs, linux-doc, linux-media, dri-devel, linaro-mm-sig,
	Li Wang, Mengmeng Zhao

From: Mengmeng Zhao <zhaomengmeng@kylinos.cn>

This series adds dma-buf read/write support for ext4. The dma-buf direct
I/O infrastructure allows dma-buf to be handed to file I/O as an iov_iter,
but currently it only supports raw block devices. To better serve the
GPU-NVMe direct access through normal filesystems, prior work for XFS has
been discussed at [1]. We are also interested in this field and working on
it [2].

The series is based on v7.4-rc2 (7475ea8b5861), which already contains
the common dma-buf direct I/O infrastructure, so it no longer depends on a
separate base tree.
Patches 1-2 carry the block and iomap prerequisites from Nitesh Shetty and
Anuj Gupta:
- bdev_init_dma_buf_io_ctx in patch 1 was moved to block/bdev.c as
suggested by Christoph.
- iomap_file_init_dma_buf_io_ctx from that series is not carried. ext4
calls bdev_init_dma_buf_io_ctx directly, and the capability check is
handled by FMODE_CAN_DMABUF_IO.

The design is:
- FMODE_CAN_DMABUF_IO marks files that can be the target of dma-buf I/O;
  a filesystem sets it at open time for inodes whose data can be reached
  without the page cache.
- dma_buf_io_ctx_create() refuses files that lack the flag and checks the
  current f_flags for O_DIRECT at registration.
- As F_SETFL can clear O_DIRECT afterwards, the paths that would fall back
  to buffered or copied I/O still need per-I/O checks in the callers.
- DAX is rechecked per I/O because it can be enabled after open.
- iomap must not ask for a buffered fallback on behalf of a dma-buf
  iterator: -ENOTBLK would be refused by the callers and would turn a
  failure into a successful transfer of zero bytes.

Patch 3 keeps the buffered fallback out of dma-buf I/O, patches 4-7 add
the refusals on the common paths and the capability flag, and patch 8
enables ext4.

Known limitation: 
1. A dma-buf read that reaches a hole or an unwritten
extent fails as a whole, even when an earlier mapped extent was already
transferred into the buffer, so the caller does not learn how much of the
dma-buf was filled.  Reporting the prefix instead would return a short
read, which callers cannot tell apart from the end of the file, and both
the buffered and the direct path normally hide holes by zero-filling.
Probing the mapping before submitting anything would fix it, but that
belongs to the common iomap series.

2. A refused dma-buf I/O reaches the caller as -EOPNOTSUPP through
iomap_dio_set_error(), which also emits an fserror notification even
though no I/O was submitted.  The report could be limited to requests
that did submit a bio, since iomap_dio_bio_iter() accounts dio->size at
submission time, but that changes what fserror users see for every iomap
filesystem, so this version leaves it as it is and asks the fserror
maintainers.

Testing:
- io_uring dma-buf suite (udmabuf + REGISTER_BUFFERS_UPDATE + READ_FIXED /
  WRITE_FIXED) against ext4 on a PCIe NVMe namespace, all passed.
- xfstests -g quick on ext4 devices: 689 tests ran, 11 reported  failures,
  all of them environment related, no failure is attributable to this 
  series.

[1] https://lore.kernel.org/linux-xfs/20261016091919.971295-1-anuj1072538@gmail.com/
[2] https://lore.kernel.org/all/20260908131545.105987-1-liwang@kylinos.cn/

Changelog:
==========
RFC v2:
- Rebased onto v7.4-rc2 and dropped the dependency on a separate base
  tree; the block and iomap prerequisites are patches 1-2.
- Added patch 3, which reports why a dma-buf direct I/O could not be done
  instead of asking for a buffered fallback that the callers refuse.
- Split the block changes: patch 4 only factors the integrity check
  into a helper, and patch 5 refuses a dma-buf bio in the inline
  encryption fallback, which is where the data pages are walked
  instead of in blk_mq_submit_bio(). (Christoph)
- Dropped the mm/filemap and iomap_file_buffered_write() guards; the
  refusals now happen in the callers that would fall back to buffered
  or copied I/O. (Christoph)
- Added the FMODE_CAN_DMABUF_IO flag and use it to check whether a bdev or
  a filesystem can do dma-buf I/O. (Christoph)

RFC v1:
- https://lore.kernel.org/all/20261105065847.196540-1-mengmeng.zhao@linux.dev/

Mengmeng Zhao (6):
  iomap: don't ask for a buffered fallback for dma-buf iterators
  blk-mq: factor out a dma-buf bio refusal helper
  blk-crypto: refuse dma-buf bios in the fallback path
  fs: add FMODE_CAN_DMABUF_IO and require it for dma-buf I/O contexts
  dax: refuse dma-buf iterators in dax_iomap_rw()
  ext4: support dma-buf registered buffers for direct I/O

Nitesh Shetty (2):
  block: factor out bdev_init_dma_buf_io_ctx()
  iomap: add dma-buf direct I/O guards

 .../filesystems/iomap/operations.rst          |  3 ++
 block/bdev.c                                  | 14 ++++++
 block/blk-crypto.c                            |  8 ++++
 block/blk-mq.c                                | 24 ++++++----
 block/fops.c                                  | 12 +----
 drivers/dma-buf/dma-buf-io.c                  | 13 ++++--
 fs/dax.c                                      |  4 ++
 fs/ext4/ext4.h                                | 11 +++++
 fs/ext4/file.c                                | 44 +++++++++++++++++--
 fs/iomap/direct-io.c                          | 41 +++++++++++++++--
 include/linux/blkdev.h                        |  8 ++++
 include/linux/fs.h                            |  8 +++-
 12 files changed, 159 insertions(+), 31 deletions(-)


base-commit: 7475ea8b58616b33c04afb976cf0fbaad9dd63fb
-- 
2.43.0


^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2026-11-13  7:31 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-13  7:06 [RFC PATCH v2 0/8] ext4: Add dma-buf read/write support Mengmeng Zhao
2026-11-13  7:06 ` [RFC PATCH v2 1/8] block: factor out bdev_init_dma_buf_io_ctx() Mengmeng Zhao
2026-11-13  7:24   ` sashiko-bot
2026-11-13  7:06 ` [RFC PATCH v2 2/8] iomap: add dma-buf direct I/O guards Mengmeng Zhao
2026-11-13  7:31   ` sashiko-bot
2026-11-13  7:06 ` [RFC PATCH v2 3/8] iomap: don't ask for a buffered fallback for dma-buf iterators Mengmeng Zhao
2026-11-13  7:28   ` sashiko-bot
2026-11-13  7:06 ` [RFC PATCH v2 4/8] blk-mq: factor out a dma-buf bio refusal helper Mengmeng Zhao
2026-11-13  7:12   ` sashiko-bot
2026-11-13  7:06 ` [RFC PATCH v2 5/8] blk-crypto: refuse dma-buf bios in the fallback path Mengmeng Zhao
2026-11-13  7:24   ` sashiko-bot
2026-11-13  7:06 ` [RFC PATCH v2 6/8] fs: add FMODE_CAN_DMABUF_IO and require it for dma-buf I/O contexts Mengmeng Zhao
2026-11-13  7:24   ` sashiko-bot
2026-11-13  7:06 ` [RFC PATCH v2 7/8] dax: refuse dma-buf iterators in dax_iomap_rw() Mengmeng Zhao
2026-11-13  7:25   ` sashiko-bot
2026-11-13  7:06 ` [RFC PATCH v2 8/8] ext4: support dma-buf registered buffers for direct I/O Mengmeng Zhao
2026-11-13  7:26   ` sashiko-bot

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.