From: Keith Busch <kbusch@meta.com>
To: <linux-block@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>
Cc: <dm-devel@lists.linux.dev>, <hch@lst.de>, <axboe@kernel.dk>,
<brauner@kernel.org>, <djwong@kernel.org>,
<viro@zeniv.linux.org.uk>, Keith Busch <kbusch@kernel.org>,
Hannes Reinecke <hare@kernel.org>
Subject: [PATCH RESEND 4/5] zloop: set dma_alignment from the backing files for direct I/O
Date: Mon, 20 Jul 2026 13:10:56 -0700 [thread overview]
Message-ID: <20260720201057.1862857-5-kbusch@meta.com> (raw)
In-Reply-To: <20260720201057.1862857-1-kbusch@meta.com>
From: Keith Busch <kbusch@kernel.org>
Direct I/O request's use pages handed to the backing files unchanged, so
the backing's DMA alignment requirement applies. Track dio_mem_align and
advertise it as the device's dma_alignment so we communicate proper
limits and misaligned I/O is rejected here instead of reaching the
backend.
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
drivers/block/zloop.c | 35 +++++++++++++++++++++++++----------
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/block/zloop.c b/drivers/block/zloop.c
index 55eeb6aac0ea3..f97a20cfdb7ce 100644
--- a/drivers/block/zloop.c
+++ b/drivers/block/zloop.c
@@ -144,6 +144,7 @@ struct zloop_device {
unsigned int nr_conv_zones;
unsigned int max_open_zones;
unsigned int block_size;
+ unsigned int dio_mem_align;
spinlock_t open_zones_lock;
struct list_head open_zones_lru_list;
@@ -1037,20 +1038,30 @@ static int zloop_get_block_size(struct zloop_device *zlo,
struct kstat st;
/*
- * If the FS block size is lower than or equal to 4K, use that as the
- * device block size. Otherwise, fallback to the FS direct IO alignment
- * constraint if that is provided, and to the FS underlying device
- * physical block size if the direct IO alignment is unknown.
+ * Use the dio alignment of the file system if provided. The incoming
+ * request's bio_vec is forwarded to the backing file unchanged, so its
+ * required memory alignment becomes the device's dma_alignment when
+ * used for direct-io.
*/
- if (file_inode(zone->file)->i_sb->s_blocksize <= SZ_4K)
- zlo->block_size = file_inode(zone->file)->i_sb->s_blocksize;
- else if (!vfs_getattr(&zone->file->f_path, &st, STATX_DIOALIGN, 0) &&
- (st.result_mask & STATX_DIOALIGN))
+ if (!vfs_getattr(&zone->file->f_path, &st, STATX_DIOALIGN, 0) &&
+ (st.result_mask & STATX_DIOALIGN)) {
zlo->block_size = st.dio_offset_align;
- else if (sb_bdev)
+ zlo->dio_mem_align = st.dio_mem_align - 1;
+ } else if (sb_bdev) {
zlo->block_size = bdev_physical_block_size(sb_bdev);
- else
+ zlo->dio_mem_align = bdev_dma_alignment(sb_bdev);
+ } else {
zlo->block_size = SECTOR_SIZE;
+ zlo->dio_mem_align = SECTOR_SIZE - 1;
+ }
+
+ /*
+ * Prefer the FS block size for the device block size when it is no
+ * larger than 4K; otherwise keep the direct I/O / physical block size
+ * selected above.
+ */
+ if (file_inode(zone->file)->i_sb->s_blocksize <= SZ_4K)
+ zlo->block_size = file_inode(zone->file)->i_sb->s_blocksize;
if (zlo->zone_capacity & ((zlo->block_size >> SECTOR_SHIFT) - 1)) {
pr_err("Zone capacity is not aligned to block size %u\n",
@@ -1279,6 +1290,10 @@ static int zloop_ctl_add(struct zloop_options *opts)
lim.physical_block_size = zlo->block_size;
lim.logical_block_size = zlo->block_size;
+ /* Direct I/O forwards the request pages to the backing files as-is. */
+ if (!opts->buffered_io)
+ lim.dma_alignment = max_t(unsigned int, zlo->dio_mem_align,
+ SECTOR_SIZE - 1);
if (zlo->zone_append)
lim.max_hw_zone_append_sectors = lim.max_hw_sectors;
lim.max_open_zones = zlo->max_open_zones;
--
2.52.0
next prev parent reply other threads:[~2026-07-20 20:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 20:10 [PATCH RESEND 0/5] block: validate direct I/O memory alignment Keith Busch
2026-07-20 20:10 ` [PATCH RESEND 1/5] block: use blkdev_iov_iter_get_pages status for errors Keith Busch
2026-07-20 20:10 ` [PATCH RESEND 2/5] block: fix dio leak on metadata mapping error Keith Busch
2026-07-20 20:10 ` [PATCH RESEND 3/5] loop: set dma_alignment from the backing file for direct I/O Keith Busch
2026-07-20 20:10 ` Keith Busch [this message]
2026-07-20 20:10 ` [PATCH RESEND 5/5] block: validate user space vectors during extraction Keith Busch
2026-07-29 19:15 ` [PATCH RESEND 0/5] block: validate direct I/O memory alignment Keith Busch
2026-07-29 19:18 ` Jens Axboe
2026-07-29 20:03 ` Keith Busch
2026-07-29 23:34 ` Jens Axboe
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=20260720201057.1862857-5-kbusch@meta.com \
--to=kbusch@meta.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=hare@kernel.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 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.