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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: Digital signature
