aboutsummaryrefslogtreecommitdiff
path: root/drivers/block
diff options
context:
space:
mode:
authorGravatar Jens Axboe <axboe@kernel.dk> 2024-05-11 08:37:52 -0600
committerGravatar Jens Axboe <axboe@kernel.dk> 2024-05-13 17:51:06 -0600
commit928b607d1a0941f02899e5490201ec071d5d4ff5 (patch)
treea2364dec8613a1d96313e004f46d5d8f76be52f1 /drivers/block
parentMerge tag 'tag-chrome-platform-firmware-for-v6.10' of git://git.kernel.org/pu... (diff)
downloadlinux-928b607d1a0941f02899e5490201ec071d5d4ff5.tar.gz
linux-928b607d1a0941f02899e5490201ec071d5d4ff5.tar.bz2
linux-928b607d1a0941f02899e5490201ec071d5d4ff5.zip
ublk_drv: set DMA alignment mask to 3
By default, this will be 511, as that's the block layer default. But drivers these days can support memory alignments that aren't tied to the sector sizes, instead just being limited by what the DMA engine supports. An example is NVMe, where it's generally set to a 32-bit or 64-bit boundary. As ublk itself doesn't really care, just set it low enough that we don't run into issues with NVMe where the required O_DIRECT memory alignment is now more restrictive on ublk than it is on the underlying device. This was triggered by spurious -EINVAL returns on O_DIRECT IO on a setup with ublk managing NVMe devices, which previously worked just fine on the NVMe device itself. With the alignment relaxed, the test works fine. Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'drivers/block')
-rw-r--r--drivers/block/ublk_drv.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index 176657dce3e3..4e159948c912 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -2178,6 +2178,7 @@ static int ublk_ctrl_start_dev(struct ublk_device *ub, struct io_uring_cmd *cmd)
.virt_boundary_mask = p->virt_boundary_mask,
.max_segments = USHRT_MAX,
.max_segment_size = UINT_MAX,
+ .dma_alignment = 3,
};
struct gendisk *disk;
int ret = -EINVAL;