linux.git/fs/nfs/callback_proc.c, branch v5.4

NFS4: Add a trace event to record invalid CB sequence IDs

2019-07-09T14:30:25+00:00

Help debug NFSv4 callback failures.

Signed-off-by: Chuck Lever 
Signed-off-by: Anna Schumaker

NFSv4.2 copy do not allocate memory under the lock

2018-11-22T18:54:46+00:00

Bruce pointed out that we shouldn't allocate memory while holding
a lock in the nfs4_callback_offload() and handle_async_copy()
that deal with a racing CB_OFFLOAD and reply to COPY case.

Signed-off-by: Olga Kornievskaia 
Signed-off-by: Trond Myklebust

NFSv4: Fix an Oops during delegation callbacks

2018-11-13T22:15:17+00:00

If the server sends a CB_GETATTR or a CB_RECALL while the filesystem is
being unmounted, then we can Oops when releasing the inode in
nfs4_callback_getattr() and nfs4_callback_recall().

Signed-off-by: Trond Myklebust

NFSv4: Fix a sleep in atomic context in nfs4_callback_sequence()

2018-08-15T16:05:15+00:00

We must drop the lock before we can sleep in referring_call_exists().

Reported-by: Jia-Ju Bai 
Fixes: 045d2a6d076a ("NFSv4.1: Delay callback processing...")
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Trond Myklebust 
Signed-off-by: Anna Schumaker

NFS handle COPY reply CB_OFFLOAD call race

2018-08-09T16:56:39+00:00

It's possible that server replies back with CB_OFFLOAD call and
COPY reply at the same time such that client will process
CB_OFFLOAD before reply to COPY. For that keep a list of pending
callback stateids received and then before waiting on completion
check the pending list.

Cleanup any pending copies on the client shutdown.

Signed-off-by: Olga Kornievskaia 
Signed-off-by: Anna Schumaker

NFS add support for asynchronous COPY

2018-08-09T16:56:39+00:00

Change xdr to always send COPY asynchronously.

Keep the list copies send in a list under a server structure.
Once copy is sent, it waits on a completion structure that will
be signalled by the callback thread that receives CB_OFFLOAD.

If CB_OFFLOAD returned an error and even if it returned partial
bytes, ignore them (as we can't commit without a verifier to
match) and return an error.

Signed-off-by: Olga Kornievskaia 
Signed-off-by: Anna Schumaker

NFS CB_OFFLOAD xdr

2018-08-09T16:56:38+00:00

Signed-off-by: Olga Kornievskaia 
Signed-off-by: Anna Schumaker

NFSv4.1: Fix a potential layoutget/layoutrecall deadlock

2018-07-26T20:25:25+00:00

If the client is sending a layoutget, but the server issues a callback
to recall what it thinks may be an outstanding layout, then we may find
an uninitialised layout attached to the inode due to the layoutget.
In that case, it is appropriate to return NFS4ERR_NOMATCHING_LAYOUT
rather than NFS4ERR_DELAY, as the latter can end up deadlocking.

Signed-off-by: Trond Myklebust

pNFS: Parse the results of layoutget on open even if permissions checks fail

2018-07-26T20:25:25+00:00

Even if the results of the permissions checks failed, we should parse
the results of the layout on open call so that we can return the
layout if required.
Note that we also want to ignore the sequence counter for whether or not
a layout recall occurred. If the recall pertained to our OPEN, then the
callback will know, and will attempt to wait for us to finih processing
anyway.

Signed-off-by: Trond Myklebust

pNFS: Don't update the stateid when replying NFS4ERR_DELAY to a layout recall

2018-07-26T20:25:24+00:00

RFC5661 doesn't state directly that the client should update the layout
stateid if it returns NFS4ERR_NOMATCHING_LAYOUT in response to a recall,
however it does state that this error will "cleanly indicate completion"
on par with returning the layout. For this reason, we assume that the
client should update the layout stateid. The Linux pNFS server definitely
does expect this behaviour.

However, if the client replies NFS4ERR_DELAY, then it is stating that
the recall was not processed, so it would be very wrong to update the
layout stateid.

Signed-off-by: Trond Myklebust