IB/mthca: Avoid recycling old FMR R_Keys too soon
authorOlaf Kirch <okir@lst.de>
Tue, 29 Apr 2008 20:46:53 +0000 (13:46 -0700)
committerRoland Dreier <rolandd@cisco.com>
Tue, 29 Apr 2008 20:46:53 +0000 (13:46 -0700)
commit0bfe151cc4049f3f304adf28b37ea5437d02ad96
tree4e67ca79ec441896bd9cfde98268eb287987989e
parentbbdc2821db041fb07ffa52e4a0e1ebb5410790e9
IB/mthca: Avoid recycling old FMR R_Keys too soon

When a FMR is unmapped, mthca resets the map count to 0, and clears
the upper part of the R_Key which is used as the sequence counter.

This poses a problem for RDS, which uses ib_fmr_unmap as a fence
operation.  RDS assumes that after issuing an unmap, the old R_Keys
will be invalid for a "reasonable" period of time. For instance,
Oracle processes uses shared memory buffers allocated from a pool of
buffers.  When a process dies, we want to reclaim these buffers -- but
we must make sure there are no pending RDMA operations to/from those
buffers.  The only way to achieve that is by using unmap and sync the
TPT.

However, when the sequence count is reset on unmap, there is a high
likelihood that a new mapping will be given the same R_Key that was
issued a few milliseconds ago.

To prevent this, don't reset the sequence count when unmapping a FMR.

Signed-off-by: Olaf Kirch <olaf.kirch@oracle.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
drivers/infiniband/hw/mthca/mthca_mr.c