diff options
author | Michael S. Tsirkin <mst@mellanox.co.il> | 2006-01-31 03:22:29 +0300 |
---|---|---|
committer | Roland Dreier <rolandd@cisco.com> | 2006-01-31 03:22:29 +0300 |
commit | e3aa31c517cb6fd0a3d8b23e6a7e71a6aafc2393 (patch) | |
tree | 97c1ca504dc60a7b380be402b91af59a4a8f8e04 /drivers/infiniband/hw/mthca/mthca_dev.h | |
parent | 8e9e5f4f5eb1d44ddabfd1ddea4ca4e4244a9ffb (diff) | |
download | linux-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