This operation is mandatory for servers to implement.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We're currently ignoring the callback security parameters specified in
create_session, and just assuming the client wants auth_sys, because
that's all the current linux client happens to care about.  But this
could cause us callbacks to fail to a client that wanted something
different.

For now, all we're doing is no longer ignoring the uid and gid passed in
the auth_sys case.  Further patches will add support for auth_null and
gss (and possibly use more of the auth_sys information; the spec wants
us to use exactly the credential we're passed, though it's hard to
imagine why a client would care).
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

These conditions would indeed indicate bugs in the code, but if we want
to hear about them we're likely better off warning and returning than
immediately dying while holding file_lock_lock.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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

The object type in the cache of lockowner_slab is wrong, and it is
better to fix it.

Cc: stable@vger.kernel.org
Signed-off-by: NYanchuan Nian <ycnian@gmail.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

The variable inode is initialized but never used
otherwise, so remove the unused variable.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

When a confirmed client expires, we normally also need to expire any
stable storage record which would allow that client to reclaim state on
the next boot.  We forgot to do this in some cases.  (For example, in
destroy_clientid, and in the cases in exchange_id and create_session
that destroy and existing confirmed client.)

But in most other cases, there's really no harm to calling
nfsd4_client_record_remove(), because it is a no-op in the case the
client doesn't have an existing

The single exception is destroying a client on shutdown, when we want to
keep the stable storage records so we can recognize which clients will
be allowed to reclaim when we come back up.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Both nfsd4_init_conn and alloc_init_session are probing the callback
channel, harmless but pointless.

Also, nfsd4_init_conn should probably be probing in the "unknown" case
as well.  In fact I don't see any harm to just doing it unconditionally
when we get a new backchannel connection.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Before we had to delay expiring a client till we'd found out whether the
session and connection allocations would succeed.  That's no longer
necessary.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

This will allow some further simplification.
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>

Do the initialization in the caller, and clarify that the only failure
ever possible here was due to allocation.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

It'll be useful to have connection allocation and initialization as
separate functions.

Also, note we'd been ignoring the alloc_conn error return in
bind_conn_to_session.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

This could simplify the logic a little later.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Something like creating a client with setclientid and then trying to
confirm it with create_session may not crash the server, but I'm not
completely positive of that, and in any case it's obviously bad client
behavior.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

And remove some mostly obsolete comments.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

I added cr_flavor to the data compared in same_creds without any
justification, in d5497fc6 "nfsd4: move
rq_flavor into svc_cred".

Recent client changes then started making

	mount -osec=krb5 server:/export /mnt/
	echo "hello" >/mnt/TMP
	umount /mnt/
	mount -osec=krb5i server:/export /mnt/
	echo "hello" >/mnt/TMP

to fail due to a clid_inuse on the second open.

Mounting sequentially like this with different flavors probably isn't
that common outside artificial tests.  Also, the real bug here may be
that the server isn't just destroying the former clientid in this case
(because it isn't good enough at recognizing when the old state is
gone).  But it prompted some discussion and a look back at the spec, and
I think the check was probably wrong.  Fix and document.

Cc: stable@kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

simplifies a bunch of callers...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Somehow we ended up with identical functions "nfs4_free_stateid" and
"free_generic_stateid".
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Processes that open and close multiple files may end up setting this
oo_last_closed_stid without freeing what was previously pointed to.
This can result in a major leak, visible for example by watching the
nfsd4_stateids line of /proc/slabinfo.
Reported-by: NCyril B. <cbay@excellency.fr>
Tested-by: NCyril B. <cbay@excellency.fr>
Cc: stable@vger.kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

struct file_lock is pretty large and really ought not live on the stack.
On my x86_64 machine, they're almost 200 bytes each.

    (gdb) p sizeof(struct file_lock)
    $1 = 192

...allocate them dynamically instead.
Reported-by: NAl Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

The code checks for a NULL filp and handles it gracefully just before
this BUG_ON.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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

locks.c doesn't use the BKL anymore and there is no fi_perfile field.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

NFSd's boot_time represents grace period start point in time.
Signed-off-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Passed network namespace replaced hard-coded init_net
Signed-off-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

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

This patch adds recall_lock hold to nfsd_forget_delegations() to protect
nfsd_process_n_delegations() call.
Also, looks like it would be better to collect delegations to some local
on-stack list, and then unhash collected list. This split allows to
simplify locking, because delegation traversing is protected by recall_lock,
when delegation unhash is protected by client_mutex.
Signed-off-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

This fixes a wrong check for same cr_principal in same_creds

Introduced by 8fbba96e "nfsd4: stricter
cred comparison for setclientid/exchange_id".

Cc: stable@vger.kernel.org
Signed-off-by: NVivek Trivedi <vtrivedi018@gmail.com>
Signed-off-by: NNamjae Jeon <linkinjeon@gmail.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We don't need to keep openowners around in the >=4.1 case, because they
aren't needed to handle CLOSE replays any more (that's a problem for
sessions).  And doing so causes unexpected failures on a subsequent
destroy_clientid to fail.

We probably also need something comparable for lock owners on last
unlock.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Note we can simplify the error handling a little by doing the truncate
earlier.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Share a little common logic.  And note the comments here are a little
out of date (e.g. we don't always create new state in the "new" case any
more.)
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

According to RFC 5661, the TEST_STATEID operation is not allowed to
return NFS4ERR_STALE_STATEID.  In addition, RFC 5661 says:

15.1.16.5.  NFS4ERR_STALE_STATEID (Error Code 10023)

   A stateid generated by an earlier server instance was used.  This
   error is moot in NFSv4.1 because all operations that take a stateid
   MUST be preceded by the SEQUENCE operation, and the earlier server
   instance is detected by the session infrastructure that supports
   SEQUENCE.

I triggered NFS4ERR_STALE_STATEID while testing the Linux client's
NOGRACE recovery.  Bruce suggested an additional test that could be
useful to client developers.

Lastly, RFC 5661, section 18.48.3 has this:

 o  Special stateids are always considered invalid (they result in the
    error code NFS4ERR_BAD_STATEID).

An explicit check is made for those state IDs to avoid printk noise.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Initiate a CB probe when a new connection with the correct direction is added
to a session (IFF backchannel is marked as down).  Without this a
BIND_CONN_TO_SESSION has no effect on the internal backchannel state, which
causes the server to reply to every SEQUENCE op with the
SEQ4_STATUS_CB_PATH_DOWN flag set until DESTROY_SESSION.
Signed-off-by: NWeston Andros Adamson <dros@netapp.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Most frequent symptom was a BUG triggering in expire_client, with the
server locking up shortly thereafter.

Introduced by 508dc6e1 "nfsd41:
free_session/free_client must be called under the client_lock".

Cc: stable@kernel.org
Cc: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Whoops: first, I reimplemented the already-existing has_resources
without noticing; second, I got the test backwards.  I did pick a better
name, though.  Combine the two....
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

In the NFSv4.1 client-reboot case we're currently removing the client's
previous state in exchange_id.  That's wrong--we should be waiting till
the confirming create_session.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>