IB/mthca: Don't cancel commands on a signal
authorMichael S. Tsirkin <mst@mellanox.co.il>
Tue, 31 Jan 2006 00:22:29 +0000 (16:22 -0800)
committerRoland Dreier <rolandd@cisco.com>
Tue, 31 Jan 2006 00:22:29 +0000 (16:22 -0800)
commite3aa31c517cb6fd0a3d8b23e6a7e71a6aafc2393
tree97c1ca504dc60a7b380be402b91af59a4a8f8e04
parent8e9e5f4f5eb1d44ddabfd1ddea4ca4e4244a9ffb
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>
drivers/infiniband/hw/mthca/mthca_cmd.c
drivers/infiniband/hw/mthca/mthca_mcg.c