On 21/03/2018 19:46, Jason Gunthorpe wrote:
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.
It works fine with this patch-set. However, I would really like to find
a better solution for the standard kernel API. Maybe always use __user
pointer and set the KERNEL_DS / USER_DS?
Jason
Matan
--
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
