aboutsummaryrefslogtreecommitdiff
path: root/fs/hfsplus
diff options
context:
space:
mode:
authorKrishna Kumar <krkumar2@in.ibm.com>2006-09-29 11:51:49 -0700
committerRoland Dreier <rolandd@cisco.com>2006-10-02 14:52:15 -0700
commit6e35aabee125999f4b3c01326f5339fa74a89259 (patch)
tree8cc49d3d79b5dda31b0b947e80b55cd1d42b0583 /fs/hfsplus
parent675a027c3db25a439f6ea744bb0c284f983dbfb9 (diff)
RDMA/cma: Fix device removal race
The race is as follows: A process : cma_process_remove() calls cma_remove_id_dev(), which sets id state to CMA_DEVICE_REMOVAL and calls wait_event(dev_remove). B process : cma_req_handler() had incremented dev_remove, and calls cma_acquire_ib_dev() and on failure calls cma_release_remove(), which does a wake_up of cma_process_remove(). Then cma_req_handler() calls rdma_destroy_id(); A Process : cma_remove_id_dev() gets woken and checks the state of id, and since it is still (wrongly) CMA_DEVICE_REMOVAL, it calls notify_user(id) and if that fails, the caller - cma_process_remove() calls rdma_destroy_id(id). Two processes can call rdma_destroy_id(), resulting in one de-referencing kfreed id_priv. Fix is for process B to set CMA_DESTROYING in cma_req_handler() so that process A will return instead of doing a rdma_destroy_id(). Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com> Signed-off-by: Sean Hefty <sean.hefty@intel.com> Signed-off-by: Roland Dreier <rolandd@cisco.com>
Diffstat (limited to 'fs/hfsplus')
0 files changed, 0 insertions, 0 deletions