summaryrefslogtreecommitdiff
path: root/drivers/infiniband/hw/mthca/mthca_dev.h
diff options
context:
space:
mode:
authorMichael S. Tsirkin <mst@mellanox.co.il>2006-01-31 03:22:29 +0300
committerRoland Dreier <rolandd@cisco.com>2006-01-31 03:22:29 +0300
commite3aa31c517cb6fd0a3d8b23e6a7e71a6aafc2393 (patch)
tree97c1ca504dc60a7b380be402b91af59a4a8f8e04 /drivers/infiniband/hw/mthca/mthca_dev.h
parent8e9e5f4f5eb1d44ddabfd1ddea4ca4e4244a9ffb (diff)
downloadlinux-e3aa31c517cb6fd0a3d8b23e6a7e71a6aafc2393.tar.xz
IB/mthca: Don't cancel commands on a signal
We have run into the following problem: if a task receives a signal while in the process of e.g. destroying a resource (which could be because the relevant file was closed) mthca could bail out from trying to take a command interface semaphore without performing the appropriate command to tell hardware that the resource is being destroyed. As a result we see messages like ib_mthca 0000:04:00.0: HW2SW_CQ failed (-4) In this case, hardware could access the resource after the memory has been freed, possibly causing memory corruption. A simple solution is to replace down_interruptible() by down() in command interface activation. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> [ It's also not safe to bail out on multicast table operations, since they may be invoked on the cleanup path too. So use down() for mcg_table.sem too. ] Signed-off-by: Roland Dreier <rolandd@cisco.com>
Diffstat (limited to 'drivers/infiniband/hw/mthca/mthca_dev.h')
0 files changed, 0 insertions, 0 deletions