IB/fmr: ib_flush_fmr_pool() may wait too long
authorRoland Dreier <rolandd@cisco.com>
Tue, 12 Dec 2006 19:50:19 +0000 (11:50 -0800)
committerRoland Dreier <rolandd@cisco.com>
Tue, 12 Dec 2006 19:50:19 +0000 (11:50 -0800)
commitf47e22c6e4225f40e0dd662398e2cb204f6ec8ed
treecb8721c67941f3b261d6310830d4bb94f0b0ed9d
parente1036502e5263851259d147771226161e5ccc85a
IB/fmr: ib_flush_fmr_pool() may wait too long

ib_flush_fmr_pool() stashes away the request generation number
properly, but then goes ahead and rereads it every time it tests
whether the flush generation number has caught up.  This means that
there is a theoretical possibility of livelock, if the request
generation number keeps getting bumped and the flush generation number
never catches up.  The fix is simple: use the request generation
number read at the beginning of the function.

Also, atomic_inc() followed by atomic_read() can be replaced with
atomic_int_return().  There's no real requirement for atomicity here
but we might as well shrink the code.

This bug was discovered using David Binderman's list of "set but never
used" warnings from icc.

Signed-off-by: Roland Dreier <rolandd@cisco.com>
drivers/infiniband/core/fmr_pool.c