kernel/fs/nfs/callback_proc.c, branch linux-5.1.y

NFSv4.2 copy do not allocate memory under the lock

2018-11-22T18:54:46Z

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:17Z

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:15Z

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:39Z

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:39Z

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:38Z

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

NFSv4.1: Fix a potential layoutget/layoutrecall deadlock

2018-07-26T20:25:25Z

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:25Z

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:24Z

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

pNFS: Don't discard layout segments that are marked for return

2018-07-26T20:25:24Z

If there are layout segments that are marked for return, then we need to ensure that pnfs_mark_matching_lsegs_return() does not just silently discard them, but it should tell the caller that there is a layoutreturn scheduled. Signed-off-by: Trond Myklebust