On Wed, Mar 21, 2018 at 07:41:44PM +0200, Matan Barak wrote:
> On 21/03/2018 19:23, Jason Gunthorpe wrote:
> >On Wed, Mar 21, 2018 at 06:37:11PM +0200, Matan Barak wrote:
> >>On 21/03/2018 18:31, Jason Gunthorpe wrote:
> >>>On Wed, Mar 21, 2018 at 06:17:27PM +0200, Matan Barak wrote:
> >>>
> >>>>>So only the kernel macro is wrong, please fix it to
> >>>>>
> >>>>> #define RDMA_UAPI_PTR(_type, _name) __aligned_u64 _name
> >>>>>
> >>>>
> >>>>By doing this, you're loosing the type information. Why not
> >>>>defining it both in user-space and kernel as union {_type _name;
> >>>>__aligned_u64 _name ## _data_u64; }
> >>>
> >>>The kernel can't use the pointer, so why define it for it?
> >>>
> >>
> >>The kernel code could use this type directly. For example, if we have a ULP
> >>that wants to use esp flow action directly, it'll have to use this as a
> >>pointer.
> >
> >Too dangerous to have a pointer potentially to userspace memory
> >without a __user annotation..
> >
>
> I know, but giving up on the compiler's type checkings (in ULPs) is
> dangerous as well :(
ULPs can't use the same struct if it has a user pointer, the kernel
API will have to do somthing different.
> >I don't think the uapi types and kernel internal types can really be
> >mixed.
>
> I don't have a strong opinion here. Maybe we can leave it as
> #define RDMA_UAPI_PTR(_type, _name) _type *_name
> and redefine it as
Bleck, that is just as problematic as the union.
> #define RDMA_UAPI_PTR(_type, _name) __aligned_u64 _name
Does this definition cause any problems with the current patch set? If
no then lets use that.
Jason
--
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
