Re: [RFC ABI 0/8] Netlink-based IOCTLs RDMA ABI

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

On Tue, May 24, 2016 at 07:37:13PM +0000, Hefty, Sean wrote:
> > struct ib_uverbs_ioctl_hdr {
> > 	__u32 length;
> 
> FWIW, I limited length to 16-bits, to prevent passing massive amounts of data between user space and the kernel as a single transfer.

We are preventing it in the code
 988 #define IB_UVERBS_MAX_CMD_SZ    4096
....
1096 static long ib_uverbs_ioctl(struct file *filp, unsigned int cmd,
1097                             unsigned long arg)
1098 {
...
1141         if (hdr.length > IB_UVERBS_MAX_CMD_SZ || hdr.length <= sizeof(hdr)) {
1142                 pr_debug("invalid uverbs ioctl command length %d\n", hdr.length);
1143                 return -EINVAL;
1144         }

> 
> > 	__u16 flags;
> 
> 16-bit flags seems limiting.

These flags will be relevant to IOCTL header only, and if we consume them all, It will be sign
to move to new IOCTL number.

> 
> > 	__u16 object_type;
> > 	__u16 reserved;
> > 	/* First 8 actions are common to all objects */
> > 	__u16 action;
> > 	__u32 user_handler;
> > 	/*
> > 	 * These fields represent core response only,
> > 	 * provider's response is given as a netlink attribute.
> > 	 */
> > 	struct ib_uverbs_uptr resp;
> 
> This is associating the kernel ABI with a specific implementation of user space components.

I don't see any specific in the proposed ABI.

> 
> Ioctl implementations I looked at treated the ioctl buffer as input-output (except for read only or write only ioctl's).  Maybe there's examples of redirecting the response to separate buffer(s)?
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]