Commit Graph

516 Commits

Author SHA1 Message Date
J. Bruce Fields
32f16b3823 nfsd4: remove some dprintk's and a comment
The comment is redundant, and if we really want dprintk's here they'd
probably be better in the common (check-slot_seqid) code.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:31 -04:00
J. Bruce Fields
778df3f0fe nfsd4: return "real" sequence id in confirmed case
The client should ignore the returned sequence_id in the case where the
CONFIRMED flag is set on an exchange_id reply--and in the unconfirmed
case "1" is always the right response.  So it shouldn't actually matter
what we return here.

We could continue returning 1 just to catch clients ignoring the spec
here, but I'd rather be generous.  Other things equal, returning the
existing sequence_id seems more informative.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:27 -04:00
J. Bruce Fields
0f1ba0ef21 nfsd4: fix exchange_id to return confirm flag
Otherwise nfsd4_set_ex_flags writes over the return flags.

Reported-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:21 -04:00
J. Bruce Fields
7447758be7 nfsd4: clarify that renewing expired client is a bug
This can't happen:
	- cl_time is zeroed only by unhash_client_locked, which is only
	  ever called under both the state lock and the client lock.
	- every caller of renew_client() should have looked up a
	  (non-expired) client and then called renew_client() all
	  without dropping the state lock.
	- the only other caller of renew_client_locked() is
	  release_session_client(), which first checks under the
	  client_lock that the cl_time is nonzero.

So make it clear that this is a bug, not something we handle.  I can't
quite bring myself to make this a BUG(), though, as there are a lot of
renew_client() callers, and returning here is probably safer than a
BUG().

We'll consider making it a BUG() after some more cleanup.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:14 -04:00
J. Bruce Fields
90d700b779 nfsd4: simpler ordering of setclientid_confirm checks
The cases here divide into two main categories:

	- if there's an uncomfirmed record with a matching verifier,
	  then this is a "normal", succesful case: we're either creating
	  a new client, or updating an existing one.
	- otherwise, this is a weird case: a replay, or a server reboot.

Reordering to reflect that makes the code a bit more concise and the
logic a lot easier to understand.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:07 -04:00
J. Bruce Fields
f3d03b9202 nfsd4: setclientid: remove pointless assignment
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:06 -04:00
J. Bruce Fields
8695b90ac3 nfsd4: fix error return in non-matching-creds case
Note CLID_INUSE is for the case where two clients are trying to use the
same client-provided long-form client identifiers.  But what we're
looking at here is the server-returned shorthand client id--if those
clash there's a bug somewhere.

Fix the error return, pull the check out into common code, and do the
check unconditionally in all cases.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:04 -04:00
J. Bruce Fields
788c1eba50 nfsd4: fix setclientid_confirm same_cred check
New clients are created only by nfsd4_setclientid(), which always gives
any new client a unique clientid.  The only exception is in the
"callback update" case, in which case it may create an unconfirmed
client with the same clientid as a confirmed client.  In that case it
also checks that the confirmed client has the same credential.

Therefore, it is pointless for setclientid_confirm to check whether a
confirmed and unconfirmed client with the same clientid have matching
credentials--they're guaranteed to.

Instead, it should be checking whether the credential on the
setclientid_confirm matches either of those.  Otherwise, it could be
anyone sending the setclientid_confirm.  Granted, I can't see why anyone
would, but still it's probalby safer to check.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:03 -04:00
J. Bruce Fields
34b232bb37 nfsd4: merge 3 setclientid cases to 2
Boy, is this simpler.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:02 -04:00
J. Bruce Fields
8f9307119d nfsd4: pull out common code from setclientid cases
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:01 -04:00
J. Bruce Fields
ad72aae5ad nfsd4: merge last two setclientid cases
The code here is mostly the same.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:30:00 -04:00
J. Bruce Fields
63db46328a nfsd4: setclientid/confirm comment cleanup
Be a little more concise.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:59 -04:00
J. Bruce Fields
e98479b8d6 nfsd4: setclientid remove unnecessary terms from a logical expression
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:58 -04:00
J. Bruce Fields
d5497fc693 nfsd4: move rq_flavor into svc_cred
Move the rq_flavor into struct svc_cred, and use it in setclientid and
exchange_id comparisons as well.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:58 -04:00
J. Bruce Fields
8fbba96e5b nfsd4: stricter cred comparison for setclientid/exchange_id
The typical setclientid or exchange_id will probably be performed with a
credential that maps to either root or nobody, so comparing just uid's
is unlikely to be useful.  So, use everything else we can get our hands
on.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:57 -04:00
J. Bruce Fields
03a4e1f6dd nfsd4: move principal name into svc_cred
Instead of keeping the principal name associated with a request in a
structure that's private to auth_gss and using an accessor function,
move it to svc_cred.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:55 -04:00
J. Bruce Fields
631fc9ea05 nfsd4: allow removing clients not holding state
RFC 5661 actually says we should allow an exchange_id to remove a
matching client, even if the exchange_id comes from a different
principal, *if* the victim client lacks any state.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:55 -04:00
J. Bruce Fields
136e658d62 nfsd4: rearrange exchange_id logic to simplify
Minor cleanup: it's simpler to have separate code paths for the update
and non-update cases.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:54 -04:00
J. Bruce Fields
2dbb269dfe nfsd4: exchange_id cleanup: comments
Make these comments a bit more concise and uniform.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:53 -04:00
J. Bruce Fields
83e08fd46c nfsd4: exchange_id cleanup: local shorthands for repeated tests
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:52 -04:00
J. Bruce Fields
1a308118c2 nfsd4: allow an EXCHANGE_ID to kill a 4.0 client
Following rfc 5661 section 2.4.1, we can permit a 4.1 client to remove
an established 4.0 client's state.

(But we don't allow updates.)

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:52 -04:00
J. Bruce Fields
ea236d0704 nfsd4: exchange_id: check creds before killing confirmed client
We mustn't allow a client to destroy another client with established
state unless it has the right credential.

And some minor cleanup.

(Note: our comparison of credentials is actually pretty bogus currently;
that will need to be fixed in another patch.)

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:51 -04:00
J. Bruce Fields
2786cc3a05 nfsd4: exchange_id error cleanup
There's no point to the dprintk here as the main proc_compound loop
already does this.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:50 -04:00
J. Bruce Fields
11ae681052 nfsd4: exchange_id has a pointless copy
We just verified above that these two verifiers are already the same.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:50 -04:00
Jeff Layton
ce0fc43c5a nfsd: wrap all accesses to st_deny_bmap
Handle the st_deny_bmap in a similar fashion to the st_access_bmap. Add
accessor functions and use those instead of bare bitops.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:48 -04:00
Jeff Layton
82c5ff1b14 nfsd: wrap accesses to st_access_bmap
Currently, we do this for the most part with "bare" bitops, but
eventually we'll need to expand the share mode code to handle access
and deny modes on other nodes.

In order to facilitate that code in the future, move to some generic
accessor functions. For now, these are mostly static inlines, but
eventually we'll want to move these to "real" functions that are
able to handle multi-node configurations or have a way to "swap in"
new operations to be done in lieu of or in conjunction with these
atomic bitops.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:47 -04:00
Jeff Layton
3a3286147f nfsd: make test_share a bool return
All of the callers treat the return that way already.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:46 -04:00
Jeff Layton
5ae037e599 nfsd: consolidate set_access and set_deny
These functions are identical. Also, rename them to bmap_to_share_mode
to better reflect what they do, and have them just return the result
instead of passing in a pointer to the storage location.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:46 -04:00
Chuck Lever
f07ea10dc8 NFSD: SETCLIENTID_CONFIRM returns NFS4ERR_CLID_INUSE too often
According to RFC 3530bis, the only items SETCLIENTID_CONFIRM processing
should be concerned with is the clientid, clientid verifier, and
principal.  The client's IP address is not supposed to be interesting.

And, NFS4ERR_CLID_INUSE is meant only for principal mismatches.

I triggered this logic with a prototype UCS client -- one that
uses the same nfs_client_id4 string for all servers.  The client
mounted our server via its IPv4, then via its IPv6 address.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:45 -04:00
J. Bruce Fields
57b7b43b40 nfsd4: int/__be32 fixes
In each of these cases there's a simple unambiguous correct choice, and
no actual bug.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:37 -04:00
J. Bruce Fields
2355c59644 nfsd4: fix missing "static"
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:35 -04:00
J. Bruce Fields
bfa4b36525 nfsd: state.c should include current_stateid.h
OK, admittedly I'm mainly just trying to shut sparse up.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-05-31 20:29:35 -04:00
Jeff Layton
33dcc481ed nfsd: don't use locks_in_grace to determine whether to call nfs4_grace_end
It's possible that lockd or another lock manager might still be on the
list after we call nfsd4_end_grace. If the laundromat thread runs
again at that point, then we could end up calling nfsd4_end_grace more
than once.

That's not only inefficient, but calling nfsd4_recdir_purge_old more
than once could be problematic. Fix this by adding a new global
"grace_ended" flag and use that to determine whether we've already
called nfsd4_grace_end.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-04-11 17:55:00 -04:00
Jeff Layton
03af42c59e nfsd: trivial: remove unused variable from nfsd4_lock
..."fp" is set but never used.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-04-11 17:54:58 -04:00
Jeff Layton
2a4317c554 nfsd: add nfsd4_client_tracking_ops struct and a way to set it
Abstract out the mechanism that we use to track clients into a set of
client name tracking functions.

This gives us a mechanism to plug in a new set of client tracking
functions without disturbing the callers. It also gives us a way to
decide on what tracking scheme to use at runtime.

For now, this just looks like pointless abstraction, but later we'll
add a new alternate scheme for tracking clients on stable storage.

Note too that this patch anticipates the eventual containerization
of this code by passing in struct net pointers in places. No attempt
is made to containerize the legacy client tracker however.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-26 11:49:47 -04:00
Jeff Layton
a52d726bbd nfsd: convert nfs4_client->cl_cb_flags to a generic flags field
We'll need a way to flag the nfs4_client as already being recorded on
stable storage so that we don't continually upcall. Currently, that's
recorded in the cl_firststate field of the client struct. Using an
entire u32 to store a flag is rather wasteful though.

The cl_cb_flags field is only using 2 bits right now, so repurpose that
to a generic flags field. Rename NFSD4_CLIENT_KILL to
NFSD4_CLIENT_CB_KILL to make it evident that it's part of the callback
flags. Add a mask that we can use for existing checks that look to see
whether any flags are set, so that the new flags don't interfere.

Convert all references to cl_firstate to the NFSD4_CLIENT_STABLE flag,
and add a new NFSD4_CLIENT_RECLAIM_COMPLETE flag.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-26 11:49:47 -04:00
J. Bruce Fields
1df00640c9 Merge nfs containerization work from Trond's tree
The nfs containerization work is a prerequisite for Jeff Layton's reboot
recovery rework.
2012-03-26 11:48:54 -04:00
Chuck Lever
ab4684d156 NFSD: Fix nfs4_verifier memory alignment
Clean up due to code review.

The nfs4_verifier's data field is not guaranteed to be u32-aligned.
Casting an array of chars to a u32 * is considered generally
hazardous.

We can fix most of this by using a __be32 array to generate the
verifier's contents and then byte-copying it into the verifier field.

However, there is one spot where there is a backwards compatibility
constraint: the do_nfsd_create() call expects a verifier which is
32-bit aligned.  Fix this spot by forcing the alignment of the create
verifier in the nfsd4_open args structure.

Also, sizeof(nfs4_verifer) is the size of the in-core verifier data
structure, but NFS4_VERIFIER_SIZE is the number of octets in an XDR'd
verifier.  The two are not interchangeable, even if they happen to
have the same value.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-20 15:36:15 -04:00
Trond Myklebust
8f199b8262 NFSD: Fix warnings when NFSD_DEBUG is not defined
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-20 15:34:19 -04:00
Benny Halevy
508dc6e110 nfsd41: free_session/free_client must be called under the client_lock
The session client is manipulated under the client_lock hence
both free_session and nfsd4_del_conns must be called under this lock.

This patch adds a BUG_ON that checks this condition in the
respective functions and implements the missing locks.

nfsd4_{get,put}_session helpers were moved to the C file that uses them
so to prevent use from external files and an unlocked version of
nfsd4_put_session is provided for external use from nfs4xdr.c

Signed-off-by: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-06 18:13:35 -05:00
Benny Halevy
e27f49c33b nfsd41: refactor nfsd4_deleg_xgrade_none_ext logic out of nfsd4_process_open2
Handle the case where the nfsv4.1 client asked to uprade or downgrade
its delegations and server returns no delegation.

In this case, op_delegate_type is set to NFS4_OPEN_DELEGATE_NONE_EXT
and op_why_no_deleg is set respectively to WND4_NOT_SUPP_{UP,DOWN}GRADE

Signed-off-by: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-06 18:13:35 -05:00
Benny Halevy
4aa8913cb0 nfsd41: refactor nfs4_open_deleg_none_ext logic out of nfs4_open_delegation
When a 4.1 client asks for a delegation and the server returns none
op_delegate_type is set to NFS4_OPEN_DELEGATE_NONE_EXT
and op_why_no_deleg is set to either WND4_CONTENTION or WND4_RESOURCE.
Or, if the client sent a NFS4_SHARE_WANT_CANCEL (which it is not supposed
to ever do until our server supports delegations signaling),
op_why_no_deleg is set to WND4_CANCELLED.

Note that for WND4_CONTENTION and WND4_RESOURCE, the xdr layer is hard coded
at this time to encode boolean FALSE for ond_server_will_push_deleg /
ond_server_will_signal_avail.

Signed-off-by: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-06 18:13:34 -05:00
J. Bruce Fields
a8ae08ebf1 nfsd4: fix recovery-entry leak nfsd startup failure
Another leak on error

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-06 18:13:32 -05:00
Jeff Layton
a6d6b7811c nfsd4: fix recovery-dir leak on nfsd startup failure
The current code never calls nfsd4_shutdown_recdir if nfs4_state_start
returns an error. Also, it's better to go ahead and consolidate these
functions since one is just a trivial wrapper around the other.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-06 18:13:25 -05:00
J. Bruce Fields
393d8ed80f nfsd4: purge stable client records with insufficient state
To escape having your stable storage record purged at the end of the
grace period, it's not sufficient to simply have performed a
setclientid_confirm; you also need to meet the same requirements as
someone creating a new record: either you should have done an open or
open reclaim (in the 4.0 case) or a reclaim_complete (in the 4.1 case).

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-06 18:13:24 -05:00
J. Bruce Fields
1255a8f36c nfsd4: don't set cl_firststate on first reclaim in 4.1 case
We set cl_firststate when we first decide that a client will be
permitted to reclaim state on next boot.  This happens:

	- for new 4.0 clients, when they confirm their first open
	- for returning 4.0 clients, when they reclaim their first open
	- for 4.1+ clients, when they perform reclaim_complete

We also use cl_firststate to decide whether a reclaim_complete has
already been performed, in the 4.1+ case.

We were setting it on 4.1 open reclaims, which caused spurious
COMPLETE_ALREADY errors on RECLAIM_COMPLETE from an nfs4.1 client with
anything to reclaim.

Reported-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-03-06 18:13:23 -05:00
Benny Halevy
d24433cdc9 nfsd41: implement NFS4_SHARE_WANT_NO_DELEG, NFS4_OPEN_DELEGATE_NONE_EXT, why_no_deleg
Respect client request for not getting a delegation in NFSv4.1
Appropriately return delegation "type" NFS4_OPEN_DELEGATE_NONE_EXT
and WND4_NOT_WANTED reason.

[nfsd41: add missing break when encoding op_why_no_deleg]
Signed-off-by: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-02-17 18:38:53 -05:00
Bryan Schumaker
03cfb42025 NFSD: Clean up the test_stateid function
When I initially wrote it, I didn't understand how lists worked so I
wrote something that didn't use them.  I think making a list of stateids
to test is a more straightforward implementation, especially compared to
especially compared to decoding stateids while simultaneously encoding
a reply to the client.

Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-02-17 18:38:52 -05:00
Benny Halevy
2c8bd7e0d1 nfsd41: split out share_access want and signal flags while decoding
Signed-off-by: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-02-17 18:38:42 -05:00
Benny Halevy
00b5f95a26 nfsd41: share_access_to_flags should consider only nfs4.x share_access flags
Currently, it will not correctly ignore any nfsv4.1 signal flags
if the client sends them.

Signed-off-by: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2012-02-17 11:50:36 -05:00