[IBAL] Fix TO_LONG_PTR use in IOCTLs.
authorleonidk <leonidk@ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86>
Sun, 13 Jul 2008 10:54:52 +0000 (10:54 +0000)
committerleonidk <leonidk@ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86>
Sun, 13 Jul 2008 10:54:52 +0000 (10:54 +0000)
commitaf49741c0539633dbb215b6593f3423084b1f9d1
tree3cf57f91cdf01c881e14508545f297aaab5d04bc
parenta44fc817fe8185fcffd09e7fcc94698d764e8c64
[IBAL] Fix TO_LONG_PTR use in IOCTLs.

Some IOCTLs transfer API structures with embedded pointers.  These embedded pointers use the TO_LONG_PTR macro to pad everything out so that __ptr64 isn't used.  The idea here is fine, but the change to eliminate the __ptr64 was riddled with problems that weren't caught by the find/replace brute force code changes.

Specifically, you had code like this:

>core\al\user\ual_mr.c, ual_reg_mem@67
>
>       /* Clear the mr_ioctl */
>       cl_memclr( &mr_ioctl, sizeof(mr_ioctl) );

In theory, no uninitialized upper 32-bits of a TO_LONG_PTR structure would get sent to the kernel.

>       mr_ioctl.in.h_pd = h_pd->obj.hdl;
>       mr_ioctl.in.mem_create = *p_mr_create;

Oops, the mem_create in the IOCTL buffer was overwritten with the caller's structure, which may have uninitialized padding.  This isn't subsequently cleared, effectively defeating the purpose of the memclr.

>+      mr_ioctl.in.mem_create.vaddr_padding =
>+ (ULONG_PTR)p_mr_create->vaddr;

Pretty much every instance of embedded structures in IOCTLs was broken in this way.  There were cases where things were closer to being right:

>core\al\user\ual_qp.c, ual_create_qp@313
>        */
>       qp_ioctl.in.h_pd = h_pd->obj.hdl;
>       qp_ioctl.in.qp_create = *p_qp_create;

Ok, same copy issue as above...

>       qp_ioctl.in.qp_create.h_rq_cq =
>               (ib_cq_handle_t)HDL_TO_PTR(p_qp_create->h_rq_cq->obj.hdl);
>       qp_ioctl.in.qp_create.h_sq_cq =
>
> (ib_cq_handle_t)HDL_TO_PTR(p_qp_create->h_sq_cq->obj.hdl);

Ah, close but not quite - you have the assignment, but it only assigns the pointer part of the TO_LONG_PTR union.  The padding is still a copy of the user's structure, potentially giving an invalid handle in the kernel.  All uses of HDL_TO_PTR were eliminated as they didn't actually accomplish anything.

This patch fixes this, and always uses the 'padding' field of the TO_LONG_PTR union so that the value is always fully set.

There's also a bug fixed in UD work requests that get sent via IOCTL - the AV handle was never swizzled to its appropriate kernel handle.

Signed-off-by: Fab Tillier <ftillier@microsoft.com>
git-svn-id: svn://openib.tc.cornell.edu/gen1/trunk@1387 ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86
core/al/kernel/al_ndi_cm.c
core/al/kernel/al_proxy.c
core/al/kernel/al_proxy_cep.c
core/al/kernel/al_proxy_verbs.c
core/al/user/ual_cm_cep.c
core/al/user/ual_mr.c
core/al/user/ual_mw.c
core/al/user/ual_qp.c
inc/iba/ib_types.h