Nothing should need to be serialised with FREE_STATEID on the client,
so let's make the RPC call always asynchronous. Also constify the
stateid argument.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Tested-by: NOleg Drokin <green@linuxhacker.ru>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Right now, we're only running TEST/FREE_STATEID on the locks if
the open stateid recovery succeeds. The protocol requires us to
always do so.
The fix would be to move the call to TEST/FREE_STATEID and do it
before we attempt open recovery.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Tested-by: NOleg Drokin <green@linuxhacker.ru>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

In some cases (e.g. when the SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED sequence
flag is set) we may already know that the stateid was revoked and that the
only valid operation we can call is FREE_STATEID. In those cases, allow
the stateid to carry the information in the type field, so that we skip
the redundant call to TEST_STATEID.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Tested-by: NOleg Drokin <green@linuxhacker.ru>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Ensure we don't spam the server with test_stateid() calls for
delegations that have already been checked.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Tested-by: NOleg Drokin <green@linuxhacker.ru>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

According to RFC5661, if any of the SEQUENCE status bits
SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED,
SEQ4_STATUS_EXPIRED_SOME_STATE_REVOKED, SEQ4_STATUS_ADMIN_STATE_REVOKED,
or SEQ4_STATUS_RECALLABLE_STATE_REVOKED are set, then we need to use
TEST_STATEID to figure out which stateids have been revoked, so we
can acknowledge the loss of state using FREE_STATEID.

While we already do this for open and lock state, we have not been doing
so for all the delegations.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Tested-by: NOleg Drokin <green@linuxhacker.ru>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Allow the callers of nfs_remove_bad_delegation() to specify the stateid
that needs to be marked as bad.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Tested-by: NOleg Drokin <green@linuxhacker.ru>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

In NFSv4.1 and newer, if the server decides to revoke some or all of
the protocol state, the client is required to iterate through all the
stateids that it holds and call TEST_STATEID to determine which stateids
still correspond to valid state, and then call FREE_STATEID on the
others.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Tested-by: NOleg Drokin <green@linuxhacker.ru>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

If the server crashes while we're testing stateids for validity, then
we want to initiate session recovery. Usually, we will be calling from
a state manager thread, though, so we don't really want to wait.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Tested-by: NOleg Drokin <green@linuxhacker.ru>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

If the delegation has been marked as revoked, we don't have to test
it, because we should already have called FREE_STATEID on it.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Tested-by: NOlek Drokin <green@linuxhacker.ru>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

As described in RFC5661, section 18.46, some of the status flags exist
in order to tell the client when it needs to acknowledge the existence of
revoked state on the server and/or to recover state.
Those flags will then remain set until the recovery procedure is done.

In order to avoid looping, the client therefore needs to ignore
those particular flags while recovering.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Tested-by: NOleg Drokin <green@linuxhacker.ru>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Add a waitqueue head to the client structure. Have clients set a wait
on that queue prior to requesting a lock from the server. If the lock
is blocked, then we can use that to wait for wakeups.

Note that we do need to do this "manually" since we need to set the
wait on the waitqueue prior to requesting the lock, but requesting a
lock can involve activities that can block.

However, only do that for NFSv4.1 locks, either by compiling out
all of the waitqueue handling when CONFIG_NFS_V4_1 is disabled, or
skipping all of it at runtime if we're dealing with v4.0, or v4.1
servers that don't send lock callbacks.

Note too that even when we expect to get a lock callback, RFC5661
section 20.11.4 is pretty clear that we still need to poll for them,
so we do still sleep on a timeout. We do however always poll at the
longest interval in that case.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
[Anna: nfs4_retry_setlk() "status" should default to -ERESTARTSYS]
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

This also consolidates the waiting logic into a single function,
instead of having it spread across two like it is now.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

We need to have this info set up before adding the waiter to the
waitqueue, so move this out of the _nfs4_proc_setlk and into the
caller. That's more efficient anyway since we don't need to do
this more than once if we end up waiting on the lock.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

We want to handle the two cases differently, such that we poll more
aggressively when we don't expect a callback.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

We actually want to use TASK_INTERRUPTIBLE sleeps when we're in the
process of polling for a NFSv4 lock. If there is a signal pending when
the task wakes up, then we'll be returning an error anyway. So, we might
as well wake up immediately for non-fatal signals as well. That allows
us to return to userland more quickly in that case, but won't change the
error that userland sees.

Also, there is no need to use the *_unsafe sleep variants here, as no
vfs-layer locks should be held at this point.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Currently, the layout driver selection code always chooses the first one
from the list. That's not really ideal however, as the server can send
the list of layout types in any order that it likes. It's up to the
client to select the best one for its needs.

This patch adds an ordered list of preferred driver types and has the
selection code sort the list of available layout drivers according to it.
Any unrecognized layout type is sorted to the end of the list.

For now, the order of preference is hardcoded, but it should be possible
to make this configurable in the future.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NJ. Bruce Fields <bfields@fieldses.org>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Try all multipath addresses for a data server. The first address that
successfully connects and creates a session is the DS mount address.
All subsequent addresses are tested for session trunking and
added as aliases.
Signed-off-by: NAndy Adamson <andros@netapp.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Use an async exchange id call to test for session trunking

To conform with RFC 5661 section 18.35.4, the Non-Update on
Existing Clientid case, save the exchange id verifier in
cl_confirm and use it for the session trunking exhange id test.
Signed-off-by: NAndy Adamson <andros@netapp.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Testing an rpc_xprt for session trunking should not delay application
progress over already established transports.
Setup exchange_id to be able to be an async call to test an rpc_xprt
for session trunking use.
Signed-off-by: NAndy Adamson <andros@netapp.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Add support for the kernel parameter nfs.callback_nr_threads to set
the number of threads that will be assigned to the callback channel.

Add support for the kernel parameter nfs.nfs.max_session_cb_slots
to set the maximum size of the callback channel slot table.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

Ensure that we conform to the algorithm described in RFC5661, section
18.36.4 for when to bump the sequence id. In essence we do it for all
cases except when the RPC call timed out, or in case of the server returning
NFS4ERR_DELAY or NFS4ERR_STALE_CLIENTID.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Cc: stable@vger.kernel.org

If the server fails to set lrp->res.lrs_present in the LAYOUTRETURN reply,
then that means it believes the client holds no more layout state for that
file, and that the layout stateid is now invalid.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

Defer freeing the slot until after we have processed the results from
OPEN and LAYOUTGET. This means that the server can rely on the
mechanism in RFC5661 Section 2.10.6.3 to ensure that replies to an
OPEN or LAYOUTGET/RETURN RPC call don't race with the callbacks that
apply to them.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

For operations like OPEN or LAYOUTGET, which return recallable state
(i.e. delegations and layouts) we want to enable the mechanism for
resolving recall races in RFC5661 Section 2.10.6.3.
To do so, we will want to defer bumping the slot's sequence number until
we have finished processing the RPC results.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

If CB_SEQUENCE tells us that the processing of this request depends on
the completion of one or more referring triples (see RFC 5661 Section
2.10.6.3), delay the callback processing until after the RPC requests
being referred to have completed.
If we end up delaying for more than 1/2 second, then fall back to
returning NFS4ERR_DELAY in reply to the callback.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

Make a helper function nfs4_set_lease_period() and have
nfs41_setup_state_renewal() and nfs4_do_fsinfo() use it.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

Use the minor version ops cached in struct nfs_client instead of looking
them up again.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

Make it static
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

That's already being taken care of in pnfs_layout_remove_lseg().
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

Ensure nfs42_layoutstat_done() layoutget don't open code layout stateid
invalidation.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

If the layout was completely returned, then ignore the returned layout
stateid.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

We want to recover the open stateid if there is no layout stateid
and/or the stateid argument matches an open stateid.
Otherwise throw out the existing layout and recover from scratch, as
the layout stateid is bad.

Fixes: 183d9e7b ("pnfs: rework LAYOUTGET retry handling")
Cc: stable@vger.kernel.org # 4.7
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Reviewed-by: NJeff Layton <jlayton@redhat.com>

They are not the same error, and need to be handled differently.

Fixes: 183d9e7b ("pnfs: rework LAYOUTGET retry handling")
Cc: stable@vger.kernel.org # 4.7
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Reviewed-by: NJeff Layton <jlayton@redhat.com>

Fix up nfs4_do_handle_exception() so that it can check if the operation
that received the NFS4ERR_BAD_STATEID was using a defunct delegation.
Apply that to the case of SETATTR, which will currently return EIO
in some cases where this happens.
Reported-by: NOlga Kornievskaia <kolga@netapp.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

If a pNFS client sets hdr->pgio_done_cb, then we should not overwrite that
in nfs4_proc_read_setup()

Fixes: 75bf47eb ("pNFS/flexfile: Fix erroneous fall back to...")
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

Olga Kornievskaia reports that the following test fails to trigger
an OPEN_DOWNGRADE on the wire, and only triggers the final CLOSE.

	fd0 = open(foo, RDRW)   -- should be open on the wire for "both"
	fd1 = open(foo, RDONLY)  -- should be open on the wire for "read"
	close(fd0) -- should trigger an open_downgrade
	read(fd1)
	close(fd1)

The issue is that we're missing a check for whether or not the current
state transitioned from an O_RDWR state as opposed to having transitioned
from a combination of O_RDONLY and O_WRONLY.
Reported-by: NOlga Kornievskaia <aglo@umich.edu>
Fixes: cd9288ff ("NFSv4: Fix another bug in the close/open_downgrade code")
Cc: stable@vger.kernel.org # 2.6.33+
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

We must call nfs4_handle_exception() on BAD_STATEID errors. The only
exception is if the stateid argument turns out to be a layout stateid
that is declared invalid.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Reviewed-by: NJeff Layton <jlayton@poochiereds.net>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>

nfs4_handle_exception() relies on the caller setting the 'inode' field
in the struct nfs4_exception argument when the error applies to a
delegation.
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
Reviewed-by: NJeff Layton <jlayton@poochiereds.net>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>