Including the full clientid in the on-the-wire stateid allows more
reliable detection of bad vs. expired stateid's, simplifies code, and
ensures we won't reuse the opaque part of the stateid (as we currently
do when the same openowner closes and reopens the same file).
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We no longer need is_deleg_stateid, for example.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Keep around an unhashed copy of the final stateid after the last close
using an openowner, and when identifying a replay, match against that
stateid instead of just against the open owner id.  Free it the next
time the seqid is bumped or the stateowner is destroyed.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

I want at least one more bit here.  So, let's haul out the caps lock key
and add a flags field.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

For IPv6 local address, lockd can not callback to client for
missing scope id when binding address at inet6_bind:

 324       if (addr_type & IPV6_ADDR_LINKLOCAL) {
 325               if (addr_len >= sizeof(struct sockaddr_in6) &&
 326                   addr->sin6_scope_id) {
 327                       /* Override any existing binding, if another one
 328                        * is supplied by user.
 329                        */
 330                       sk->sk_bound_dev_if = addr->sin6_scope_id;
 331               }
 332
 333               /* Binding to link-local address requires an interface */
 334               if (!sk->sk_bound_dev_if) {
 335                       err = -EINVAL;
 336                       goto out_unlock;
 337               }

Replacing svc_addr_u by sockaddr_storage, let rqstp->rq_daddr contains more info
besides address.
Reviewed-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NMi Jinlong <mijinlong@cn.fujitsu.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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>