Hi,
This patch is usefull in case GRANTED_RES are accepted. In
that case, a race condition may theoretically happen, triggering
possibly client thinking falsely it holds a lock. Here is the
scenario:
a client asks for a blocking lock. The server can't give it,
and sends NLM_LCK_BLOCKED. After a while the server can grant
the lock and send a GRANTED_MSG. The client get the call, but
for any reason cannot get the lock and respond with a GRANTED_RES
with status NLM_LCK_DENIED. This call gets lost. The server then
retries a GRANTED_MSG, but for any reason it fails to send
the GRANTED_MSG and thus is still in call (and in_call is set for
this block).
Now the client asks one more time for the lock
and the server responds with NLM_LCK_GRANTED because the client
allready holds the lock. As in_call is set, the block isn't removed.
Now imagine that the GRANTED_RES with NLM_LCK_DENIED reaches
the server. In nlmsvc_grant_reply the server will do
nlmsvc_delete_block(block, 1) and thus remove the lock. The client still
thinks he holds the lock.
To avoid that, in the patch, in case b_done is set, nlmsvc_grant_reply
returns without doing anything.
Pat