- 13 Sep, 2011 12 commits
-
-
J. Bruce Fields authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Test_stateid should handle delegation stateid's as well. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
It's simpler to look up delegation stateid's in the same hash table as any other stateid. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
We want delegations to share more with open/lock stateid's, so first we'll pull out some of the common stuff we want to share. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Note this is actually open-stateid specific. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
We're only using those flags to choose lock or open stateid's at this point. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Move most of this into helper functions. Also move the non-CONFIRM case into caller, providing a helper function for that purpose. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Minor cleanup. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 07 Sep, 2011 2 commits
-
-
J. Bruce Fields authored
We'll use this elsewhere. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
The stateowner has some fields that only make sense for openowners, and some that only make sense for lockowners, and I find it a lot clearer if those are separated out. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 04 Sep, 2011 1 commit
-
-
J. Bruce Fields authored
Move the CLOSE_STATE case into the unique caller that cares about it rather than putting it in preprocess_seqid_op. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 03 Sep, 2011 1 commit
-
-
J. Bruce Fields authored
I don't see the point of having this check in nfs4_preprocess_seqid_op() when it's only needed by the one caller. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 02 Sep, 2011 2 commits
-
-
J. Bruce Fields authored
Sometimes the single-exit style is good, sometimes it's unnecessarily convoluted.... Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 01 Sep, 2011 4 commits
-
-
J. Bruce Fields authored
This is used only as a local variable. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Maybe we'll bring it back some day, but we don't have much real use for it now. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
If open fails with any error other than nfserr_replay_me, then the main nfsd4_proc_compound() loop continues unconditionally to nfsd4_encode_operation(), which will always call encode_seqid_op_tail. Thus the condition we check for here does not occur. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
There are currently a couple races in the seqid replay code: a retransmission could come while we're still encoding the original reply, or a new seqid-mutating call could come as we're encoding a replay. So, extend the state lock over the encoding (both encoding of a replayed reply and caching of the original encoded reply). I really hate doing this, and previously added the stateowner reference-counting code to avoid it (which was insufficient)--but I don't see a less complicated alternative at the moment. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 31 Aug, 2011 9 commits
-
-
J. Bruce Fields authored
Now that the replay owner is in the cstate we can remove it from a lot of other individual operations and further simplify nfs4_preprocess_seqid_op(). Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Set the stateowner associated with a replay in one spot in nfs4_preprocess_seqid_op() and keep it in cstate. This allows removing a few lines of boilerplate from all the nfs4_preprocess_seqid_op() callers. Also turn ENCODE_SEQID_OP_TAIL into a function while we're here. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Thanks to Casey for reminding me that 5661 gives a special meaning to a value of 0 in the stateid's seqid field, so all stateid's should start out with si_generation 1. We were doing that in the open and lock cases for minorversion 1, but not for the delegation stateid, and not for openstateid's with v4.0. It doesn't *really* matter much for v4.0 or for delegation stateid's (which never get the seqid field incremented), but we may as well do the same for all of them. Reported-by: Casey Bodley <cbodley@citi.umich.edu> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Follow the recommendation from rfc3530bis for stateid generation number wraparound, simplify some code, and fix or remove incorrect comments. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
There's no reason to have two separate hash tables for open and lock stateid's. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
The trick free_stateid is using is a little cheesy, and we'll have more uses for this field later. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Wow, I wonder how long that typo's been there. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
The values here represent highest slotid numbers. Since slotid's are numbered starting from zero, the highest should be one less than the number of slots. Reported-by: Rick Macklem <rmacklem@uoguelph.ca> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
We don't need this any more. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 27 Aug, 2011 9 commits
-
-
J. Bruce Fields authored
When called with OPEN_STATE, preprocess_seqid_op only returns an open stateid, hence only an open owner. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
We've got some lock-specific code here in nfs4_preprocess_seqid_op which is only used by nfsd4_lock(). Move it to the caller. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Note that the special handling for the lock stateid case is already done by nfs4_check_openmode() (as of 02921914 "nfsd4: fix openmode checking on IO using lock stateid") so we no longer need these two cases in the caller. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
This flag doesn't really buy us anything. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Share some common code, stop doing silly things like initializing a list head immediately before adding it to a list, etc. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
These appear to be generic (for both open and lock owners), but they're actually just for open owners. This has confused me more than once. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
For all the usual reasons. (Type safety, readability.) Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
The server is returning nfserr_resource for both permanent errors and for errors (like allocation failures) that might be resolved by retrying later. Save nfserr_resource for the former and use delay/jukebox for the latter. Cc: stable@kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-