First, we shouldn't care here about the structure of the opaque part of
the stateid.  Second, this hash is really dumb.  (I'm not sure the
replacement is much better, though--to look at it another patch.)
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Test_stateid should handle delegation stateid's as well.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

It's simpler to look up delegation stateid's in the same hash table as
any other stateid.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Note this is actually open-stateid specific.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We're only using those flags to choose lock or open stateid's at this
point.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

Minor cleanup.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We'll use this elsewhere.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

Move the CLOSE_STATE case into the unique caller that cares about it
rather than putting it in preprocess_seqid_op.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

Sometimes the single-exit style is good, sometimes it's unnecessarily
convoluted....
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

This is used only as a local variable.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Maybe we'll bring it back some day, but we don't have much real use for
it now.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

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: NCasey Bodley <cbodley@citi.umich.edu>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Follow the recommendation from rfc3530bis for stateid generation number
wraparound, simplify some code, and fix or remove incorrect comments.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

There's no reason to have two separate hash tables for open and lock
stateid's.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

The trick free_stateid is using is a little cheesy, and we'll have more
uses for this field later.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

When called with OPEN_STATE, preprocess_seqid_op only returns an open
stateid, hence only an open owner.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

This flag doesn't really buy us anything.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Share some common code, stop doing silly things like initializing a list
head immediately before adding it to a list, etc.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

For all the usual reasons.  (Type safety, readability.)
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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: NJ. Bruce Fields <bfields@redhat.com>

Move around some of this code, simplify a bit.
Reviewed-by: NBoaz Harrosh <bharrosh@panasas.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

The nfsd4 code has a bunch of special exceptions for error returns which
map nfserr_symlink to other errors.

In fact, the spec makes it clear that nfserr_symlink is to be preferred
over less specific errors where possible.

The patch that introduced it back in 2.6.4 is "kNFSd: correct symlink
related error returns.", which claims that these special exceptions are
represent an NFSv4 break from v2/v3 tradition--when in fact the symlink
error was introduced with v4.

I suspect what happened was pynfs tests were written that were overly
faithful to the (known-incomplete) rfc3530 error return lists, and then
code was fixed up mindlessly to make the tests pass.

Delete these unnecessary exceptions.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

CLAIM_DELEGATE_CUR is used in response to a broken lease; allowing it
to break the lease and return EAGAIN leaves the client unable to make
progress in returning the delegation

nfs4_get_vfs_file() now takes struct nfsd4_open for access to the
claim type, and calls nfsd_open() with NFSD_MAY_NOT_BREAK_LEASE when
claim type is CLAIM_DELEGATE_CUR
Signed-off-by: NCasey Bodley <cbodley@citi.umich.edu>
Cc: stable@kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>