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

pNFS/flexfiles: missing error code in ff_layout_alloc_lseg()

2018-05-23T01:36:25+00:00

[ Upstream commit 662f9a105b4322b8559d448f86110e6ec24b8738 ]

If xdr_inline_decode() fails then we end up returning ERR_PTR(0).  The
caller treats NULL returns as -ENOMEM so it doesn't really hurt runtime,
but obviously we intended to set an error code here.

Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver")
Signed-off-by: Dan Carpenter 
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

NFSv4.1: RECLAIM_COMPLETE must handle NFS4ERR_CONN_NOT_BOUND_TO_SESSION

2018-05-23T01:36:22+00:00

[ Upstream commit 0048fdd06614a4ea088f9fcad11511956b795698 ]

If the server returns NFS4ERR_CONN_NOT_BOUND_TO_SESSION because we
are trunking, then RECLAIM_COMPLETE must handle that by calling
nfs4_schedule_session_recovery() and then retrying.

Reported-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Tested-by: Chuck Lever 
Signed-off-by: Sasha Levin

NFS: Fix missing pg_cleanup after nfs_pageio_cond_complete()

2018-05-23T01:33:49+00:00

[ Upstream commit 43b7d964ed30dbca5c83c90cb010985b429ec4f9 ]

Commit a7d42ddb3099727f58366fa006f850a219cce6c8 ("nfs: add mirroring
support to pgio layer") moved pg_cleanup out of the path when there was
non-sequental I/O that needed to be flushed.  The result is that for
layouts that have more than one layout segment per file, the pg_lseg is not
cleared, so we can end up hitting the WARN_ON_ONCE(req_start >= seg_end) in
pnfs_generic_pg_test since the pg_lseg will be pointing to that
previously-flushed layout segment.

Signed-off-by: Benjamin Coddington 
Fixes: a7d42ddb3099 ("nfs: add mirroring support to pgio layer")
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

NFS: Fix an incorrect type in struct nfs_direct_req

2018-05-23T01:33:42+00:00

[ Upstream commit d9ee65539d3eabd9ade46cca1780e3309ad0f907 ]

The start offset needs to be of type loff_t.

Fixed: 5fadeb47dcc5c ("nfs: count DIO good bytes correctly with mirroring")
Cc: stable@vger.kernel.org # v4.0+
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

NFS: reject request for id_legacy key without auxdata

2018-03-01T03:09:51+00:00

[ Upstream commit 49686cbbb3ebafe42e63868222f269d8053ead00 ]

nfs_idmap_legacy_upcall() is supposed to be called with 'aux' pointing
to a 'struct idmap', via the call to request_key_with_auxdata() in
nfs_idmap_request_key().

However it can also be reached via the request_key() system call in
which case 'aux' will be NULL, causing a NULL pointer dereference in
nfs_idmap_prepare_pipe_upcall(), assuming that the key description is
valid enough to get that far.

Fix this by making nfs_idmap_legacy_upcall() negate the key if no
auxdata is provided.

As usual, this bug was found by syzkaller.  A simple reproducer using
the command-line keyctl program is:

    keyctl request2 id_legacy uid:0 '' @s

Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
Reported-by: syzbot+5dfdbcf7b3eb5912abbb@syzkaller.appspotmail.com
Cc:  # v3.4+
Signed-off-by: Eric Biggers 
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

NFS: commit direct writes even if they fail partially

2018-03-01T03:09:51+00:00

[ Upstream commit 1b8d97b0a837beaf48a8449955b52c650a7114b4 ]

If some of the WRITE calls making up an O_DIRECT write syscall fail,
we neglect to commit, even if some of the WRITEs succeed.

We also depend on the commit code to free the reference count on the
nfs_page taken in the "if (request_commit)" case at the end of
nfs_direct_write_completion().  The problem was originally noticed
because ENOSPC's encountered partway through a write would result in a
closed file being sillyrenamed when it should have been unlinked.

Signed-off-by: J. Bruce Fields 
Cc: stable@vger.kernel.org
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

NFS: Add a cond_resched() to nfs_commit_release_pages()

2018-03-01T03:09:51+00:00

[ Upstream commit 7f1bda447c9bd48b415acedba6b830f61591601f ]

The commit list can get very large, and so we need a cond_resched()
in nfs_commit_release_pages() in order to ensure we don't hog the CPU
for excessive periods of time.

Reported-by: Mike Galbraith 
Cc: stable@vger.kernel.org
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

NFSv4.1 respect server's max size in CREATE_SESSION

2018-01-17T17:55:36+00:00

[ Upstream commit 033853325fe3bdc70819a8b97915bd3bca41d3af ]

Currently client doesn't respect max sizes server returns in CREATE_SESSION.
nfs4_session_set_rwsize() gets called and server->rsize, server->wsize are 0
so they never get set to the sizes returned by the server.

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

NFS: Fix a typo in nfs_rename()

2018-01-17T17:55:29+00:00

[ Upstream commit d803224c84be067754db7fa58a93f36f61566493 ]

On successful rename, the "old_dentry" is retained and is attached to
the "new_dir", so we need to call nfs_set_verifier() accordingly.

Signed-off-by: Trond Myklebust 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin

NFSv4: Fix client recovery when server reboots multiple times

2018-01-17T17:55:19+00:00

[ Upstream commit c6180a6237174f481dc856ed6e890d8196b6f0fb ]

If the server reboots multiple times, the client should rely on the
server to tell it that it cannot reclaim state as per section 9.6.3.4
in RFC7530 and section 8.4.2.1 in RFC5661.
Currently, the client is being to conservative, and is assuming that
if the server reboots while state recovery is in progress, then it must
ignore state that was not recovered before the reboot.

Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin