Home| summaryrefslogtreecommitdiff |
diff options
| author | Michal Hocko <mhocko@suse.com> | 2019-01-14 13:17:20 +0100 |
|---|---|---|
| committer | Michal Hocko <mhocko@suse.com> | 2019-01-14 13:17:20 +0100 |
| commit | f939fdb1e32fb4519afd49c8f3e6eee71b183240 (patch) | |
| tree | 3eb1b14c85e9cf906f4f41cf4605176b57c1677e | |
| parent | 210ed0b82e547c79903ee0c3ab59df9b88239ed4 (diff) | |
| parent | c8f4732de4a13dab304aec867bf6316f989bca7f (diff) | |
Merge remote-tracking branch 'origin/users/nfbrown/SLE11-SP4/for-next' into users/mhocko/SLE11-SP4/for-next
4 files changed, 160 insertions, 0 deletions
diff --git a/patches.fixes/NFSv4-Don-t-exit-the-state-manager-without-clearing-.patch b/patches.fixes/NFSv4-Don-t-exit-the-state-manager-without-clearing-.patch new file mode 100644 index 0000000000..cb4051cf5a --- /dev/null +++ b/patches.fixes/NFSv4-Don-t-exit-the-state-manager-without-clearing-.patch @@ -0,0 +1,45 @@ +From: Trond Myklebust <trond.myklebust@hammerspace.com> +Date: Mon, 5 Nov 2018 11:10:50 -0500 +Subject: [PATCH] NFSv4: Don't exit the state manager without clearing + NFS4CLNT_MANAGER_RUNNING +Git-commit: 21a446cf186570168b7281b154b1993968598aca +Patch-mainline: v4.20 +References: git-fixes + +If we exit the NFSv4 state manager due to a umount, then we can end up +leaving the NFS4CLNT_MANAGER_RUNNING flag set. If another mount causes +the nfs4_client to be rereferenced before it is destroyed, then we end +up never being able to recover state. + +Fixes: 47c2199b6eb5 ("NFSv4.1: Ensure state manager thread dies on last ...") +Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> +Cc: stable@vger.kernel.org # v4.15+ +Acked-by: NeilBrown <neilb@suse.com> + +--- + fs/nfs/nfs4state.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/fs/nfs/nfs4state.c ++++ b/fs/nfs/nfs4state.c +@@ -1814,15 +1814,17 @@ static void nfs4_state_manager(struct nf + nfs4_clear_state_manager_bit(clp); + /* Did we race with an attempt to give us more work? */ + if (clp->cl_state == 0) +- break; ++ return; + if (test_and_set_bit(NFS4CLNT_MANAGER_RUNNING, &clp->cl_state) != 0) +- break; ++ return; + } while (atomic_read(&clp->cl_count) > 1); +- return; ++ goto out_drain; ++ + out_error: + printk(KERN_WARNING "Error: state manager failed on NFSv4 server %s" + " with error %d\n", clp->cl_hostname, -status); + ssleep(1); ++out_drain: + nfs4_end_drain_session(clp); + nfs4_clear_state_manager_bit(clp); + } diff --git a/patches.fixes/SUNRPC-Fix-a-potential-race-in-xprt_connect.patch b/patches.fixes/SUNRPC-Fix-a-potential-race-in-xprt_connect.patch new file mode 100644 index 0000000000..fd7fd84de0 --- /dev/null +++ b/patches.fixes/SUNRPC-Fix-a-potential-race-in-xprt_connect.patch @@ -0,0 +1,42 @@ +From: Trond Myklebust <trond.myklebust@hammerspace.com> +Date: Sat, 1 Dec 2018 23:18:00 -0500 +Subject: [PATCH] SUNRPC: Fix a potential race in xprt_connect() +Git-commit: 0a9a4304f3614e25d9de9b63502ca633c01c0d70 +Patch-mainline: v4.20 +References: git-fixes + +If an asynchronous connection attempt completes while another task is +in xprt_connect(), then the call to rpc_sleep_on() could end up +racing with the call to xprt_wake_pending_tasks(). +So add a second test of the connection state after we've put the +task to sleep and set the XPRT_CONNECTING flag, when we know that there +can be no asynchronous connection attempts still in progress. + +Fixes: 0b9e79431377d ("SUNRPC: Move the test for XPRT_CONNECTING into...") +Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> +Acked-by: NeilBrown <neilb@suse.com> + +--- + net/sunrpc/xprt.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +--- a/net/sunrpc/xprt.c ++++ b/net/sunrpc/xprt.c +@@ -742,8 +742,15 @@ void xprt_connect(struct rpc_task *task) + return; + if (xprt_test_and_set_connecting(xprt)) + return; +- xprt->stat.connect_start = jiffies; +- xprt->ops->connect(task); ++ /* Race breaker */ ++ if (!xprt_connected(xprt)) { ++ xprt->stat.connect_start = jiffies; ++ xprt->ops->connect(task); ++ } else { ++ xprt_clear_connecting(xprt); ++ task->tk_status = 0; ++ rpc_wake_up_queued_task(&xprt->pending, task); ++ } + } + } + diff --git a/patches.fixes/fscache-Fix-race-in-fscache_op_complete-due-to-split.patch b/patches.fixes/fscache-Fix-race-in-fscache_op_complete-due-to-split.patch new file mode 100644 index 0000000000..0c4bffdc9d --- /dev/null +++ b/patches.fixes/fscache-Fix-race-in-fscache_op_complete-due-to-split.patch @@ -0,0 +1,70 @@ +From: "kiran.modukuri" <kiran.modukuri@gmail.com> +Date: Mon, 26 Nov 2018 15:41:48 +0000 +Subject: [PATCH] fscache: Fix race in fscache_op_complete() due to split + atomic_sub & read +Git-commit: 3f2b7b9035107d6096ea438ea3d97dcf0481b6d2 +Patch-mainline: v4.20 +References: git-fixes + +The code in fscache_retrieval_complete is using atomic_sub followed by an +Atomic_read: + + atomic_sub(n_pages, &op->n_pages); + if (atomic_read(&op->n_pages) <= 0) + fscache_op_complete(&op->op, true); + +This causes two threads doing a decrement of n_pages to race with each +other seeing the op->refcount 0 at same time - and they end up calling +fscache_op_complete() in both the threads leading to an assertion failure. + +Fix this by using atomic_sub_return() instead of two calls. Note +that I'm using 'relaxed' rather than, say, 'release' as there aren't +multiple variables that appear to need ordering across the release. + +The oops looks something like: + +Fs-cache: Assertion failed +Fs-cache: 0 > 0 is false +... +kernel BUG at /usr/src/linux-4.4.0/fs/fscache/operation.c:449! +... +Workqueue: fscache_operation fscache_op_work_func [fscache] +... +Rip: 0010:[<ffffffffc037eacd>] fscache_op_complete+0x10d/0x180 [fscache] +... +Call Trace: + [<ffffffffc1464cf9>] cachefiles_read_copier+0x3a9/0x410 [cachefiles] + [<ffffffffc037e272>] fscache_op_work_func+0x22/0x50 [fscache] + [<ffffffff81096da0>] process_one_work+0x150/0x3f0 + [<ffffffff8109751a>] worker_thread+0x11a/0x470 + [<ffffffff81808e59>] ? __schedule+0x359/0x980 + [<ffffffff81097400>] ? rescuer_thread+0x310/0x310 + [<ffffffff8109cdd6>] kthread+0xd6/0xf0 + [<ffffffff8109cd00>] ? kthread_park+0x60/0x60 + [<ffffffff8180d0cf>] ret_from_fork+0x3f/0x70 + [<ffffffff8109cd00>] ? kthread_park+0x60/0x60 + +This seen this in 4.4.x kernels and the same bug affects fscache in latest +upstreams kernels. + +Fixes: 1bb4b7f98f36 ("FS-Cache: The retrieval remaining-pages counter needs to be atomic_t") +Signed-off-by: Kiran Kumar Modukuri <kiran.modukuri@gmail.com> +Signed-off-by: David Howells <dhowells@redhat.com> +Acked-by: NeilBrown <neilb@suse.com> + +--- + include/linux/fscache-cache.h | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/include/linux/fscache-cache.h ++++ b/include/linux/fscache-cache.h +@@ -195,8 +195,7 @@ static inline void fscache_enqueue_retri + static inline void fscache_retrieval_complete(struct fscache_retrieval *op, + int n_pages) + { +- atomic_sub(n_pages, &op->n_pages); +- if (atomic_read(&op->n_pages) <= 0) ++ if (atomic_sub_return(n_pages, &op->n_pages) <= 0) + fscache_op_complete(&op->op, true); + } + diff --git a/series.conf b/series.conf index a74a03355b..8c3f367e1d 100644 --- a/series.conf +++ b/series.conf @@ -6739,6 +6739,7 @@ patches.suse/ubifs-check-for-name-being-null-while-mounting.patch patches.fixes/0001-FS-Cache-Synchronise-object-death-state-change-vs-op.patch patches.fixes/locks-fix-unlock-when-fcntl_setlk-races-with-a-close.patch + patches.fixes/fscache-Fix-race-in-fscache_op_complete-due-to-split.patch ######################################################## # Swap-over-NFS @@ -6909,6 +6910,8 @@ patches.fixes/nlm-Ensure-callback-code-also-checks-that-the-files-.patch patches.fixes/svc-Avoid-garbage-replies-when-pc_func-returns-rpc_d.patch patches.fixes/svcrpc-don-t-leak-contexts-on-PROC_DESTROY.patch + patches.fixes/NFSv4-Don-t-exit-the-state-manager-without-clearing-.patch + patches.fixes/SUNRPC-Fix-a-potential-race-in-xprt_connect.patch ######################################################## # Netfilter |