Re: [PATCH v10 06/10] io_uring: introduce attributes for read/write and PI support

[Pavel Begunkov <asml.silence@gmail.com>]

On 11/25/24 07:06, Anuj Gupta wrote:
> Add the ability to pass additional attributes along with read/write.
> Application can populate attribute type and attibute specific information
> in 'struct io_uring_attr' and pass its address using the SQE field:
> 	__u64	attr_ptr;
> 
> Along with setting a mask indicating attributes being passed:
> 	__u64	attr_type_mask;
> 
> Overall 64 attributes are allowed and currently one attribute
> 'ATTR_TYPE_PI' is supported.
> 
> With PI attribute, userspace can pass following information:
> - flags: integrity check flags IO_INTEGRITY_CHK_{GUARD/APPTAG/REFTAG}
> - len: length of PI/metadata buffer
> - addr: address of metadata buffer
> - seed: seed value for reftag remapping
> - app_tag: application defined 16b value

The API and io_uring parts look good, I'll ask to address the
ATTR_TYPE comment below, the rest are nits, which that can be
ignored and/or delayed.

> Process this information to prepare uio_meta_descriptor and pass it down
> using kiocb->private.

I'm not sure using ->private is a good thing, but I assume it
was discussed, so I'll leave it to Jens and other folks.


> PI attribute is supported only for direct IO.
> 
> Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
> Signed-off-by: Kanchan Joshi <joshi.k@samsung.com>
> ---
>   include/uapi/linux/io_uring.h | 31 +++++++++++++
>   io_uring/io_uring.c           |  2 +
>   io_uring/rw.c                 | 82 ++++++++++++++++++++++++++++++++++-
>   io_uring/rw.h                 | 14 +++++-
>   4 files changed, 126 insertions(+), 3 deletions(-)
> 
> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
> index aac9a4f8fa9a..bf28d49583ad 100644
> --- a/include/uapi/linux/io_uring.h
> +++ b/include/uapi/linux/io_uring.h
> @@ -98,6 +98,10 @@ struct io_uring_sqe {
>   			__u64	addr3;
>   			__u64	__pad2[1];
>   		};
> +		struct {
> +			__u64	attr_ptr; /* pointer to attribute information */
> +			__u64	attr_type_mask; /* bit mask of attributes */
> +		};
>   		__u64	optval;
>   		/*
>   		 * If the ring is initialized with IORING_SETUP_SQE128, then
> @@ -107,6 +111,33 @@ struct io_uring_sqe {
>   	};
>   };
>   
> +
> +/* Attributes to be passed with read/write */
> +enum io_uring_attr_type {
> +	ATTR_TYPE_PI,
> +	/* max supported attributes */
> +	ATTR_TYPE_LAST = 64,

ATTR_TYPE sounds too generic, too easy to get a symbol collision
including with user space code.

Some options: IORING_ATTR_TYPE_PI, IORING_RW_ATTR_TYPE_PI.
If it's not supposed to be io_uring specific can be
IO_RW_ATTR_TYPE_PI

> +};
> +
> +/* sqe->attr_type_mask flags */
> +#define ATTR_FLAG_PI	(1U << ATTR_TYPE_PI)
> +/* PI attribute information */
> +struct io_uring_attr_pi {
> +		__u16	flags;
> +		__u16	app_tag;
> +		__u32	len;
> +		__u64	addr;
> +		__u64	seed;
> +		__u64	rsvd;
> +};
> +
> +/* attribute information along with type */
> +struct io_uring_attr {
> +	enum io_uring_attr_type	attr_type;

I'm not against it, but adding a type field to each attribute is not
strictly needed, you can already derive where each attr placed purely
from the mask. Are there some upsides? But again I'm not against it.

> +	/* type specific struct here */
> +	struct io_uring_attr_pi	pi;
> +};
> +
>   /*
>    * If sqe->file_index is set to this for opcodes that instantiate a new
>    * direct descriptor (like openat/openat2/accept), then io_uring will allocate
> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
> index c3a7d0197636..02291ea679fb 100644
> --- a/io_uring/io_uring.c
> +++ b/io_uring/io_uring.c
> @@ -3889,6 +3889,8 @@ static int __init io_uring_init(void)
>   	BUILD_BUG_SQE_ELEM(46, __u16,  __pad3[0]);
>   	BUILD_BUG_SQE_ELEM(48, __u64,  addr3);
>   	BUILD_BUG_SQE_ELEM_SIZE(48, 0, cmd);
> +	BUILD_BUG_SQE_ELEM(48, __u64, attr_ptr);
> +	BUILD_BUG_SQE_ELEM(56, __u64, attr_type_mask);
>   	BUILD_BUG_SQE_ELEM(56, __u64,  __pad2);
>   
>   	BUILD_BUG_ON(sizeof(struct io_uring_files_update) !=
> diff --git a/io_uring/rw.c b/io_uring/rw.c
> index 0bcb83e4ce3c..71bfb74fef96 100644
> --- a/io_uring/rw.c
> +++ b/io_uring/rw.c
> @@ -257,11 +257,54 @@ static int io_prep_rw_setup(struct io_kiocb *req, int ddir, bool do_import)
>   	return 0;
>   }
...
> @@ -902,6 +976,8 @@ static int __io_read(struct io_kiocb *req, unsigned int issue_flags)
>   	 * manually if we need to.
>   	 */
>   	iov_iter_restore(&io->iter, &io->iter_state);
> +	if (kiocb->ki_flags & IOCB_HAS_METADATA)
> +		io_meta_restore(io);

That can be turned into a helper, but that can be done as a follow up.

I'd also add a IOCB_HAS_METADATA into or around of
io_rw_should_retry(). You're relying on O_DIRECT checks, but that
sounds a bit fragile in the long run.

-- 
Pavel Begunkov