From: Anuj Gupta <anuj1072538@gmail.com>
To: asml.silence@gmail.com, hch@lst.de, djwong@kernel.org,
cem@kernel.org, brauner@kernel.org, axboe@kernel.dk
Cc: linux-block@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, joshi.k@samsung.com,
anuj20.g@samsung.com, nj.shetty@samsung.com
Subject: [RFC 3/4] iomap: add dma-buf direct I/O guards and registration helper
Date: Fri, 16 Oct 2026 14:49:13 +0530 [thread overview]
Message-ID: <20261016091919.971295-4-anuj1072538@gmail.com> (raw)
In-Reply-To: <20261016091919.971295-1-anuj1072538@gmail.com>
From: Nitesh Shetty <nj.shetty@samsung.com>
Direct I/O copies data from the CPU in three places, zero-filling
holes, inline data, and bounce pages. A dma-buf iterator has no
CPU-visible pages, so refuse it.
Reads that encounter a hole or unwritten extent therefore return
-EOPNOTSUPP for the entire operation, even if I/O for an earlier mapped
extent was already submitted.
Also add iomap_file_init_dma_buf_io_ctx(), so filesystems can register
without open-coding the DAX check. The filesystem picks the device,
iomap does the rest.
Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
---
fs/iomap/direct-io.c | 31 ++++++++++++++++++++++++++++++-
include/linux/iomap.h | 3 +++
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index 8b4039d16ce8..fc40f4367ee7 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -427,6 +427,10 @@ static int iomap_dio_bio_iter(struct iomap_iter *iter, struct iomap_dio *dio)
unsigned int alignment;
ssize_t ret = 0;
+ if (iov_iter_is_dmabuf_map(dio->submit.iter) &&
+ (iomap->flags & IOMAP_F_INTEGRITY))
+ return -EOPNOTSUPP;
+
/*
* File systems that write out of place and always allocate new blocks
* need each bio to be block aligned as that's the unit of allocation.
@@ -595,7 +599,13 @@ static int iomap_dio_bio_iter(struct iomap_iter *iter, struct iomap_dio *dio)
static int iomap_dio_hole_iter(struct iomap_iter *iter, struct iomap_dio *dio)
{
- loff_t length = iov_iter_zero(iomap_length(iter), dio->submit.iter);
+ loff_t length;
+
+ /* a device mapping cannot be zeroed from the CPU */
+ if (iov_iter_is_dmabuf_map(dio->submit.iter))
+ return -EOPNOTSUPP;
+
+ length = iov_iter_zero(iomap_length(iter), dio->submit.iter);
dio->size += length;
if (!length)
@@ -612,6 +622,10 @@ static int iomap_dio_inline_iter(struct iomap_iter *iomi, struct iomap_dio *dio)
loff_t pos = iomi->pos;
u64 copied;
+ /* inline data is copied from the CPU, which a device mapping bypasses */
+ if (iov_iter_is_dmabuf_map(iter))
+ return -EOPNOTSUPP;
+
if (WARN_ON_ONCE(!inline_data))
return -EIO;
@@ -710,6 +724,10 @@ __iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
if (!iomi.len)
return NULL;
+ /* bouncing copies the data from the CPU, which a device mapping bypasses */
+ if (iov_iter_is_dmabuf_map(iter) && (dio_flags & IOMAP_DIO_BOUNCE))
+ return ERR_PTR(-EOPNOTSUPP);
+
dio = kmalloc_obj(*dio);
if (!dio)
return ERR_PTR(-ENOMEM);
@@ -915,6 +933,17 @@ iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
}
EXPORT_SYMBOL_GPL(iomap_dio_rw);
+int iomap_file_init_dma_buf_io_ctx(struct file *file, struct block_device *bdev,
+ struct dma_buf_io_ctx *ctx)
+{
+ struct inode *inode = file_inode(file);
+
+ if (IS_DAX(inode))
+ return -EOPNOTSUPP;
+ return bdev_init_dma_buf_io_ctx(file, bdev, ctx);
+}
+EXPORT_SYMBOL_GPL(iomap_file_init_dma_buf_io_ctx);
+
struct iomap_dio_simple {
struct kiocb *iocb;
size_t size;
diff --git a/include/linux/iomap.h b/include/linux/iomap.h
index bc7ae6327dbf..ce97df81c644 100644
--- a/include/linux/iomap.h
+++ b/include/linux/iomap.h
@@ -682,6 +682,9 @@ struct iomap_dio *__iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
ssize_t iomap_dio_complete(struct iomap_dio *dio);
void iomap_dio_bio_end_io(struct bio *bio);
+int iomap_file_init_dma_buf_io_ctx(struct file *file, struct block_device *bdev,
+ struct dma_buf_io_ctx *ctx);
+
/*
* Fast path for small, block-aligned direct I/Os that map to a single
* contiguous on-disk extent.
--
2.43.0
next prev parent reply other threads:[~2026-10-16 9:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 9:19 [RFC 0/4] fs: support dma-buf backed direct I/O Anuj Gupta
2026-10-16 9:19 ` [RFC 1/4] block: factor out bdev_init_dma_buf_io_ctx() Anuj Gupta
2026-10-16 9:23 ` Christoph Hellwig
2026-10-16 9:19 ` [RFC 2/4] block: refuse a dma-buf bio for a disk the buffer was not registered on Anuj Gupta
2026-10-16 9:24 ` Christoph Hellwig
2026-10-16 9:19 ` Anuj Gupta [this message]
2026-10-16 9:26 ` [RFC 3/4] iomap: add dma-buf direct I/O guards and registration helper Christoph Hellwig
2026-10-16 9:19 ` [RFC 4/4] xfs: support dma-buf registered buffers for direct I/O Anuj Gupta
2026-10-16 9:28 ` Christoph Hellwig
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=20261016091919.971295-4-anuj1072538@gmail.com \
--to=anuj1072538@gmail.com \
--cc=anuj20.g@samsung.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=nj.shetty@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox