IB/fmr_pool: Flush serial numbers can get out of sync
authorOlaf Kirch <olaf.kirch@oracle.com>
Wed, 16 Jan 2008 17:36:27 +0000 (18:36 +0100)
committerRoland Dreier <rolandd@cisco.com>
Fri, 25 Jan 2008 22:15:42 +0000 (14:15 -0800)
commita656eb758fc6e6a42659ecf5ba34a5c5a2aeec17
tree779bc9dea9396aa1907528472108a90ef3f2bce8
parent2fe7e6f7c9f55eac24c5b3cdf56af29ab9b0ca81
IB/fmr_pool: Flush serial numbers can get out of sync

Normally, the serial numbers for flush requests and flushes executed
for an FMR pool should be in sync.

However, if the FMR pool flushes dirty FMRs because the
dirty_watermark was reached, we wake up the cleanup thread and let it
do its stuff.  As a side effect, the cleanup thread increments
pool->flush_ser, which leaves it one higher than pool->req_ser.  The
next time the user calls ib_flush_fmr_pool(), the cleanup thread will
be woken up, but ib_flush_fmr_pool() won't wait for the flush to
complete because flush_ser is already past req_ser.  This means the
FMRs that the user expects to be flushed may not have all been flushed
when the function returns.

Fix this by telling the cleanup thread to do work exclusively by
incrementing req_ser, and by moving the comparison of dirty_len and
dirty_watermark into ib_fmr_pool_unmap().

Signed-off-by: Olaf Kirch <olaf.kirch@oracle.com>
drivers/infiniband/core/fmr_pool.c