kernel.git/drivers/infiniband, branch linux-2.6.37.y

IB/cm: Bump reference count on cm_id before invoking callback

2011-03-23T19:50:07Z

commit 29963437a48475036353b95ab142bf199adb909e upstream. When processing a SIDR REQ, the ib_cm allocates a new cm_id. The refcount of the cm_id is initialized to 1. However, cm_process_work will decrement the refcount after invoking all callbacks. The result is that the cm_id will end up with refcount set to 0 by the end of the sidr req handler. If a user tries to destroy the cm_id, the destruction will proceed, under the incorrect assumption that no other threads are referencing the cm_id. This can lead to a crash when the cm callback thread tries to access the cm_id. This problem was noticed as part of a larger investigation with kernel crashes in the rdma_cm when running on a real time OS. Signed-off-by: Sean Hefty Acked-by: Doug Ledford Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman

RDMA/cma: Fix crash in request handlers

2011-03-23T19:50:06Z

commit 25ae21a10112875763c18b385624df713a288a05 upstream. Doug Ledford and Red Hat reported a crash when running the rdma_cm on a real-time OS. The crash has the following call trace: cm_process_work cma_req_handler cma_disable_callback rdma_create_id kzalloc init_completion cma_get_net_info cma_save_net_info cma_any_addr cma_zero_addr rdma_translate_ip rdma_copy_addr cma_acquire_dev rdma_addr_get_sgid ib_find_cached_gid cma_attach_to_dev ucma_event_handler kzalloc ib_copy_ah_attr_to_user cma_comp [ preempted ] cma_write copy_from_user ucma_destroy_id copy_from_user _ucma_find_context ucma_put_ctx ucma_free_ctx rdma_destroy_id cma_exch cma_cancel_operation rdma_node_get_transport rt_mutex_slowunlock bad_area_nosemaphore oops_enter They were able to reproduce the crash multiple times with the following details: Crash seems to always happen on the: mutex_unlock(&conn_id->handler_mutex); as conn_id looks to have been freed during this code path. An examination of the code shows that a race exists in the request handlers. When a new connection request is received, the rdma_cm allocates a new connection identifier. This identifier has a single reference count on it. If a user calls rdma_destroy_id() from another thread after receiving a callback, rdma_destroy_id will proceed to destroy the id and free the associated memory. However, the request handlers may still be in the process of running. When control returns to the request handlers, they can attempt to access the newly created identifiers. Fix this by holding a reference on the newly created rdma_cm_id until the request handler is through accessing it. Signed-off-by: Sean Hefty Acked-by: Doug Ledford Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman

RDMA/cxgb4: Limit MAXBURST EQ context field to 256B

2011-02-17T23:14:16Z

commit 6a09a9d6946dd516d243d072bee83fae3c683471 upstream. MAXBURST cannot exceed 256B for on-chip queues. With a 512B MAXBURST, we can lock up the chip. Signed-off-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman

RDMA/cxgb4: Set the correct device physical function for iWARP connections

2011-02-17T23:14:16Z

commit 94788657c94169171971968c9d4b6222c5e704aa upstream. The PF passed to FW was 0, causing PCI failures in an SR-IOV environment. Signed-off-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman

RDMA/cxgb4: Don't re-init wait object in init/fini paths

2011-02-17T23:14:15Z

commit db8b10167126d72829653690f57b9c7ca53c4d54 upstream. Re-initializing the wait object in rdma_init()/rdma_fini() causes a timing window which can lead to a deadlock during close. Once this deadlock hits, all RDMA activity over the T4 device will be stuck. There's no need to re-init the wait object, so remove it. Signed-off-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman

IB/uverbs: Handle large number of entries in poll CQ

2010-12-08T23:23:49Z

In ib_uverbs_poll_cq() code there is a potential integer overflow if userspace passes in a large cmd.ne. The calls to kmalloc() would allocate smaller buffers than intended, leading to memory corruption. There iss also an information leak if resp wasn't all used. Unprivileged userspace may call this function, although only if an RDMA device that uses this function is present. Fix this by copying CQ entries one at a time, which avoids the allocation entirely, and also by moving this copying into a function that makes sure to initialize all memory copied to userspace. Special thanks to Jason Gunthorpe for his help and advice. Cc: Signed-off-by: Dan Carpenter [ Monkey around with things a bit to avoid bad code generation by gcc when designated initializers are used. - Roland ] Signed-off-by: Roland Dreier

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband

2010-12-02T20:10:56Z

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband: IB: Fix information leak in marshalling code IB/pack: Remove some unused code added by the IBoE patches IB/mlx4: Fix IBoE link state IB/mlx4: Fix IBoE reported link rate mlx4_core: Workaround firmware bug in query dev cap IB/mlx4: Fix memory ordering of VLAN insertion control bits MAINTAINERS: Update NetEffect entry

Merge branches 'misc', 'mlx4' and 'nes' into for-next

2010-12-02T00:33:47Z

IB: Fix information leak in marshalling code

2010-12-02T00:33:18Z

ib_ucm_init_qp_attr() and ucma_init_qp_attr() pass struct ib_uverbs_qp_attr with reserved, qp_state, {ah_attr,alt_ah_attr}{reserved,->grh.reserved} fields uninitialized to copy_to_user(). This leads to leaking of contents of kernel stack memory to userspace. Signed-off-by: Vasiliy Kulikov Signed-off-by: Roland Dreier

IB/pack: Remove some unused code added by the IBoE patches

2010-12-02T00:30:18Z

Remove unused functions added by commit ff7f5aab354d ("IB/pack: IBoE UD packet packing support"). Signed-off-by: Or Gerlitz