Commit graph

5 commits

Author SHA1 Message Date
Trond Myklebust
aaaa99423b NLM: Ensure that nlmclnt_cancel_callback() doesn't loop forever
If the server returns NLM_LCK_DENIED_NOLOCKS, we currently retry the
 entire NLM_CANCEL request. This may end up looping forever unless the
 server changes its mind (why would it do that, though?).

 Ensure that we limit the number of retries (to 3).

 See bug# 5957 in bugzilla.kernel.org.

 Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2006-02-01 12:52:23 -05:00
Trond Myklebust
16fb24252a NLM: Fix arguments to NLM_CANCEL call
The OpenGroup docs state that the arguments "block", "exclusive" and
 "alock" must exactly match the arguments for the lock call that we are
 trying to cancel.
 Currently, "block" is always set to false, which is wrong.

 See bug# 5956 on bugzilla.kernel.org.

 Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2006-02-01 12:52:23 -05:00
Trond Myklebust
963d8fe533 RPC: Clean up RPC task structure
Shrink the RPC task structure. Instead of storing separate pointers
 for task->tk_exit and task->tk_release, put them in a structure.

 Also pass the user data pointer as a parameter instead of passing it via
 task->tk_calldata. This enables us to nest callbacks.

 Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2006-01-06 14:58:39 -05:00
Trond Myklebust
ecdbf769b2 [PATCH] NLM: fix a client-side race on blocking locks.
If the lock blocks, the server may send us a GRANTED message that
 races with the reply to our LOCK request. Make sure that we catch
 the GRANTED by queueing up our request on the nlm_blocked list
 before we send off the first LOCK rpc call.

 Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2005-06-22 16:07:42 -04:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00