On Thu, Jan 08, 2026 at 02:19:28AM -0700, Caleb Sander Mateos wrote:
> Much work has recently gone into supporting block device integrity data
> (sometimes called "metadata") in Linux. Many NVMe devices these days
> support metadata transfers and/or automatic protection information
> generation and verification. However, ublk devices can't yet advertise
> integrity data capabilities. This patch series wires up support for
> integrity data in ublk. The ublk feature is referred to as "integrity"
> rather than "metadata" to match the block layer's name for it and to
> avoid confusion with the existing and unrelated UBLK_IO_F_META.
>
> To advertise support for integrity data, a ublk server fills out the
> struct ublk_params's integrity field and sets UBLK_PARAM_TYPE_INTEGRITY.
> The struct ublk_param_integrity flags and csum_type fields use the
> existing LBMD_PI_* constants from the linux/fs.h UAPI header. The ublk
> driver fills out a corresponding struct blk_integrity.
>
> When a request with integrity data is issued to the ublk device, the
> ublk driver sets UBLK_IO_F_INTEGRITY in struct ublksrv_io_desc's
> op_flags field. This is necessary for a ublk server for which
> bi_offload_capable() returns true to distinguish requests with integrity
> data from those without.
>
> Integrity data transfers can currently only be performed via the ublk
> user copy mechanism. The overhead of zero-copy buffer registration makes
> it less appealing for the small transfers typical of integrity data.
> Additionally, neither io_uring NVMe passthru nor IORING_RW_ATTR_FLAG_PI
> currently allow an io_uring registered buffer for the integrity data.
> The ki_pos field of the struct kiocb passed to the user copy
> ->{read,write}_iter() callback gains a bit UBLKSRV_IO_INTEGRITY_FLAG for
> a ublk server to indicate whether to access the request's data or
> integrity data.
>
> Not yet supported is an analogue for the IO_INTEGRITY_CHK_*/BIP_CHECK_*
> flags to ask the ublk server to verify the guard, reftag, and/or apptag
> of a request's protection information. The user copy mechanism currently
> forbids a ublk server from reading the data/integrity buffer of a
> read-direction request. We could potentially relax this restriction for
> integrity data on reads. Alternatively, the ublk driver could verify the
> requested fields as part of the user copy operation.
>
> v4:
> - Add max_integrity_segments to struct ublk_param_integrity (Ming)
> - Move UBLKSRV_IO_INTEGRITY_FLAG to avoid overflow from
> QID + UBLKSRV_IO_BUF_OFFSET (Ming)
> - Check UBLK_F_INTEGRITY when UBLKSRV_IO_INTEGRITY_FLAG is used (Ming)
> - Initialize integrity backing file to disable integrity checks (Ming)
Hi Jens,
Can you consider to queue V4 into for-7.0/block if you are fine? So I can rebase
my BATCH_IO patchset against this one.
Thanks,
Ming