linux-stable.git/fs/nfs, branch linux-5.7.y

NFS: Fix flexfiles read failover

2020-08-21T11:07:41+00:00

[ Upstream commit 563c53e73b8b6ec842828736f77e633f7b0911e9 ]

The current mirrored read failover code is correctly resetting the mirror
index between failed reads, however it is not able to actually flip the
RPC call over to the next RPC client.
The end result is that we keep resending the RPC call to the same client
over and over.

The fix is to use the pnfs_read_resend_pnfs() mechanism to schedule a
new RPC call, but we need to add the ability to pass in a mirror
index so that we always retry the next mirror in the list.

Fixes: 166bd5b889ac ("pNFS/flexfiles: Fix layoutstats handling during read failovers")
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

nfs: Fix getxattr kernel panic and memory overflow

2020-08-21T11:07:41+00:00

[ Upstream commit b4487b93545214a9db8cbf32e86411677b0cca21 ]

Move the buffer size check to decode_attr_security_label() before memcpy()
Only call memcpy() if the buffer is large enough

Fixes: aa9c2669626c ("NFS: Client implementation of Labeled-NFS")
Signed-off-by: Jeffrey Mitchell 
[Trond: clean up duplicate test of label->len != 0]
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

nfs: nfs_file_write() should check for writeback errors

2020-08-21T11:07:39+00:00

[ Upstream commit ce368536dd614452407dc31e2449eb84681a06af ]

The NFS_CONTEXT_ERROR_WRITE flag (as well as the check of said flag) was
removed by commit 6fbda89b257f.  The absence of an error check allows
writes to be continually queued up for a server that may no longer be
able to handle them.  Fix it by adding an error check using the generic
error reporting functions.

Fixes: 6fbda89b257f ("NFS: Replace custom error reporting mechanism with generic one")
Signed-off-by: Scott Mayhew 
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

nfs: ensure correct writeback errors are returned on close()

2020-08-21T11:07:38+00:00

[ Upstream commit 67dd23f9e6fbaf163431912ef5599c5e0693476c ]

nfs_wb_all() calls filemap_write_and_wait(), which uses
filemap_check_errors() to determine the error to return.
filemap_check_errors() only looks at the mapping->flags and will
therefore only return either -ENOSPC or -EIO.  To ensure that the
correct error is returned on close(), nfs{,4}_file_flush() should call
filemap_check_wb_err() which looks at the errseq value in
mapping->wb_err without consuming it.

Fixes: 6fbda89b257f ("NFS: Replace custom error reporting mechanism with
generic one")
Signed-off-by: Scott Mayhew 
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

NFS: Don't return layout segments that are in use

2020-08-19T06:24:15+00:00

commit d474f96104bd4377573526ebae2ee212205a6839 upstream.

If the NFS_LAYOUT_RETURN_REQUESTED flag is set, we want to return the
layout as soon as possible, meaning that the affected layout segments
should be marked as invalid, and should no longer be in use for I/O.

Fixes: f0b429819b5f ("pNFS: Ignore non-recalled layouts in pnfs_layout_need_return()")
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS: Don't move layouts to plh_return_segs list while in use

2020-08-19T06:24:15+00:00

commit ff041727e9e029845857cac41aae118ead5e261b upstream.

If the layout segment is still in use for a read or a write, we should
not move it to the layout plh_return_segs list. If we do, we can end
up returning the layout while I/O is still in progress.

Fixes: e0b7d420f72a ("pNFS: Don't discard layout segments that are marked for return")
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

SUNRPC reverting d03727b248d0 ("NFSv4 fix CLOSE not waiting for direct IO compeletion")

2020-07-29T08:19:37+00:00

commit 65caafd0d2145d1dd02072c4ced540624daeab40 upstream.

Reverting commit d03727b248d0 "NFSv4 fix CLOSE not waiting for
direct IO compeletion". This patch made it so that fput() by calling
inode_dio_done() in nfs_file_release() would wait uninterruptably
for any outstanding directIO to the file (but that wait on IO should
be killable).

The problem the patch was also trying to address was REMOVE returning
ERR_ACCESS because the file is still opened, is supposed to be resolved
by server returning ERR_FILE_OPEN and not ERR_ACCESS.

Signed-off-by: Olga Kornievskaia 
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix interrupted slots by sending a solo SEQUENCE operation

2020-07-22T07:34:09+00:00

[ Upstream commit 913fadc5b105c3619d9e8d0fe8899ff1593cc737 ]

We used to do this before 3453d5708b33, but this was changed to better
handle the NFS4ERR_SEQ_MISORDERED error code. This commit fixed the slot
re-use case when the server doesn't receive the interrupted operation,
but if the server does receive the operation then it could still end up
replying to the client with mis-matched operations from the reply cache.

We can fix this by sending a SEQUENCE to the server while recovering from
a SEQ_MISORDERED error when we detect that we are in an interrupted slot
situation.

Fixes: 3453d5708b33 (NFSv4.1: Avoid false retries when RPC calls are interrupted)
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin

nfs: Fix memory leak of export_path

2020-07-16T06:13:17+00:00

[ Upstream commit 4659ed7cc8514369043053463514408ca16ad6f3 ]

The try_location function is called within a loop by nfs_follow_referral.
try_location calls nfs4_pathname_string to created the export_path.
nfs4_pathname_string allocates the memory. export_path is stored in the
nfs_fs_context/fs_context structure similarly as hostname and source.
But whereas the ctx hostname and source are freed before assignment,
export_path is not.  So if there are multiple loops, the new export_path
will overwrite the old without the old being freed.

So call kfree for export_path.

Signed-off-by: Tom Rix 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin

NFSv4 fix CLOSE not waiting for direct IO compeletion

2020-06-30T19:36:30+00:00

commit d03727b248d0dae6199569a8d7b629a681154633 upstream.

Figuring out the root case for the REMOVE/CLOSE race and
suggesting the solution was done by Neil Brown.

Currently what happens is that direct IO calls hold a reference
on the open context which is decremented as an asynchronous task
in the nfs_direct_complete(). Before reference is decremented,
control is returned to the application which is free to close the
file. When close is being processed, it decrements its reference
on the open_context but since directIO still holds one, it doesn't
sent a close on the wire. It returns control to the application
which is free to do other operations. For instance, it can delete a
file. Direct IO is finally releasing its reference and triggering
an asynchronous close. Which races with the REMOVE. On the server,
REMOVE can be processed before the CLOSE, failing the REMOVE with
EACCES as the file is still opened.

Signed-off-by: Olga Kornievskaia 
Suggested-by: Neil Brown 
CC: stable@vger.kernel.org
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman