linux.git/drivers/infiniband/core, branch v3.18.5

Merge branches 'core', 'cxgb4', 'iser', 'mlx5' and 'ocrdma' into for-next

2014-10-14T21:09:12+00:00

IB/core: Fix XRC race condition in ib_uverbs_open_qp

2014-10-14T07:30:56+00:00

In ib_uverbs_open_qp, the sharable xrc target qp is created as a
"pseudo" qp and added to a list of qp's sharing the same physical
QP.  This is done before the "pseudo" qp is assigned a uobject.

There is a race condition here if an async event arrives at the
physical qp.  If the event is handled after the pseudo qp is added to
the list, but before it is assigned a uobject, the kernel crashes in
ib_uverbs_qp_event_handler, due to trying to dereference a NULL
uobject pointer.

Note that simply checking for non-NULL is not enough, due to error
flows in ib_uverbs_open_qp.  If the failure is after assigning the
uobject, but before the qp has fully been created, we still have a
problem.

Thus, in ib_uverbs_qp_event_handler, we test that the uobject is
present, and also that it is live.

Reported-by: Matthew Finlay 
Signed-off-by: Jack Morgenstein 
Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier

IB/core: Clear AH attr variable to prevent garbage data

2014-10-14T07:29:06+00:00

During create-ah from userspace, uverbs is sending garbage data in
attr.dmac and attr.vlan_id.  This patch sets attr.dmac and
attr.vlan_id to zero.

Fixes: dd5f03beb4f7 ("IB/core: Ethernet L2 attributes in verbs/cm structures")
Signed-off-by: Devesh Sharma 
Signed-off-by: Roland Dreier

IB/core: Avoid leakage from kernel to user space

2014-10-09T07:08:40+00:00

Clear the reserved field of struct ib_uverbs_async_event_desc which is
copied to user space.

Signed-off-by: Eli Cohen 
Reviewed-by: Yann Droneaud 
Signed-off-by: Roland Dreier

Merge branches 'core', 'ipoib', 'iser', 'mlx4', 'ocrdma' and 'qib' into for-next

2014-09-22T17:05:40+00:00

IB/core: When marshaling uverbs path, clear unused fields

2014-09-22T16:46:52+00:00

When marsheling a user path to the kernel struct ib_sa_path, need
to zero smac, dmac and set the vlan id to the "no vlan" value.

Fixes: dd5f03beb4f7 ("IB/core: Ethernet L2 attributes in verbs/cm structures")
Reported-by: Aleksey Senin 
Signed-off-by: Matan Barak 
Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier

IB: ib_umem_release() should decrement mm->pinned_vm from ib_umem_get

2014-09-19T16:55:42+00:00

In debugging an application that receives -ENOMEM from ib_reg_mr(), I
found that ib_umem_get() can fail because the pinned_vm count has
wrapped causing it to always be larger than the lock limit even with
RLIMIT_MEMLOCK set to RLIM_INFINITY.

The wrapping of pinned_vm occurs because the process that calls
ib_reg_mr() will have its mm->pinned_vm count incremented.  Later a
different process with a different mm_struct than the one that
allocated the ib_umem struct ends up releasing it which results in
decrementing the new processes mm->pinned_vm count past zero and
wrapping.

I'm not entirely sure what circumstances cause a different process to
release the ib_umem than the one that allocated it but the kernel
stack trace of the freeing process from my situation looks like the
following:

    Call Trace:
     [] dump_stack+0x19/0x1b
     [] ib_umem_release+0x1f5/0x200 [ib_core]
     [] mlx4_ib_destroy_qp+0x241/0x440 [mlx4_ib]
     [] ib_destroy_qp+0x12c/0x170 [ib_core]
     [] ib_uverbs_close+0x259/0x4e0 [ib_uverbs]
     [] __fput+0xba/0x240
     [] ____fput+0xe/0x10
     [] task_work_run+0xc4/0xe0
     [] do_notify_resume+0x95/0xa0
     [] int_signal+0x12/0x17

The following patch fixes the issue by storing the pid struct of the
process that calls ib_umem_get() so that ib_umem_release and/or
ib_umem_account() can properly decrement the pinned_vm count of the
correct mm_struct.

Signed-off-by: Shawn Bohrer 
Reviewed-by: Shachar Raindel 
Signed-off-by: Roland Dreier

Merge branches 'core', 'cxgb4', 'ipoib', 'iser', 'iwcm', 'mad', 'misc', 'mlx4', 'mlx5', 'ocrdma' and 'srp' into for-next

2014-08-14T15:58:04+00:00

IB/mad: Add user space RMPP support

2014-08-11T03:36:00+00:00

Using the new registration mechanism, define a flag that indicates the
user wishes to process RMPP messages in user space rather than have
the kernel process them.

Signed-off-by: Ira Weiny 
Signed-off-by: Roland Dreier

IB/mad: add new ioctl to ABI to support new registration options

2014-08-11T03:36:00+00:00

Registrations options are specified through flags.  Definitions of flags will
be in subsequent patches.

Signed-off-by: Ira Weiny 
Signed-off-by: Roland Dreier