From: Ming Lei <ming.lei@redhat.com>
To: Caleb Sander Mateos <csander@purestorage.com>
Cc: Jens Axboe <axboe@kernel.dk>, Shuah Khan <shuah@kernel.org>,
linux-block@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org,
Stanley Zhang <stazhang@purestorage.com>,
Uday Shankar <ushankar@purestorage.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH v4 00/19] ublk: add support for integrity data
Date: Mon, 12 Jan 2026 22:45:15 +0800 [thread overview]
Message-ID: <aWUI-4Z30PlhDB_Z@fedora> (raw)
In-Reply-To: <20260108091948.1099139-1-csander@purestorage.com>
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
next prev parent reply other threads:[~2026-01-12 14:45 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-08 9:19 [PATCH v4 00/19] ublk: add support for integrity data Caleb Sander Mateos
2026-01-08 9:19 ` [PATCH v4 01/19] blk-integrity: take const pointer in blk_integrity_rq() Caleb Sander Mateos
2026-01-08 9:19 ` [PATCH v4 02/19] ublk: move ublk flag check functions earlier Caleb Sander Mateos
2026-01-08 9:19 ` [PATCH v4 03/19] ublk: support UBLK_PARAM_TYPE_INTEGRITY in device creation Caleb Sander Mateos
2026-01-08 12:14 ` Ming Lei
2026-01-08 9:19 ` [PATCH v4 04/19] ublk: set UBLK_IO_F_INTEGRITY in ublksrv_io_desc Caleb Sander Mateos
2026-01-08 9:19 ` [PATCH v4 05/19] ublk: split out ublk_copy_user_bvec() helper Caleb Sander Mateos
2026-01-08 9:19 ` [PATCH v4 06/19] ublk: split out ublk_user_copy() helper Caleb Sander Mateos
2026-01-08 9:19 ` [PATCH v4 07/19] ublk: inline ublk_check_and_get_req() into ublk_user_copy() Caleb Sander Mateos
2026-01-08 9:19 ` [PATCH v4 08/19] ublk: move offset check out of __ublk_check_and_get_req() Caleb Sander Mateos
2026-01-12 18:17 ` Alexander Atanasov
2026-01-12 18:29 ` Caleb Sander Mateos
2026-01-12 19:44 ` Alexander Atanasov
2026-01-08 9:19 ` [PATCH v4 09/19] ublk: implement integrity user copy Caleb Sander Mateos
2026-01-08 12:19 ` Ming Lei
2026-01-08 9:19 ` [PATCH v4 10/19] ublk: support UBLK_F_INTEGRITY Caleb Sander Mateos
2026-01-08 9:19 ` [PATCH v4 11/19] ublk: optimize ublk_user_copy() on daemon task Caleb Sander Mateos
2026-01-08 9:19 ` [PATCH v4 12/19] selftests: ublk: display UBLK_F_INTEGRITY support Caleb Sander Mateos
2026-01-08 9:19 ` [PATCH v4 13/19] selftests: ublk: add utility to get block device metadata size Caleb Sander Mateos
2026-01-08 12:21 ` Ming Lei
2026-01-08 9:19 ` [PATCH v4 14/19] selftests: ublk: add kublk support for integrity params Caleb Sander Mateos
2026-01-08 12:23 ` Ming Lei
2026-01-08 9:19 ` [PATCH v4 15/19] selftests: ublk: implement integrity user copy in kublk Caleb Sander Mateos
2026-01-08 12:27 ` Ming Lei
2026-01-08 9:19 ` [PATCH v4 16/19] selftests: ublk: support non-O_DIRECT backing files Caleb Sander Mateos
2026-01-08 12:35 ` Ming Lei
2026-01-08 9:19 ` [PATCH v4 17/19] selftests: ublk: add integrity data support to loop target Caleb Sander Mateos
2026-01-08 12:42 ` Ming Lei
2026-01-08 9:19 ` [PATCH v4 18/19] selftests: ublk: add integrity params test Caleb Sander Mateos
2026-01-08 12:45 ` Ming Lei
2026-01-08 9:19 ` [PATCH v4 19/19] selftests: ublk: add end-to-end integrity test Caleb Sander Mateos
2026-01-08 12:46 ` Ming Lei
2026-01-12 14:45 ` Ming Lei [this message]
2026-01-12 16:22 ` [PATCH v4 00/19] ublk: add support for integrity data 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=aWUI-4Z30PlhDB_Z@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=shuah@kernel.org \
--cc=stazhang@purestorage.com \
--cc=ushankar@purestorage.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 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.