Home Home > GIT Browse > SLE11-SP4
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichal Hocko <mhocko@suse.com>2019-01-14 13:17:20 +0100
committerMichal Hocko <mhocko@suse.com>2019-01-14 13:17:20 +0100
commitf939fdb1e32fb4519afd49c8f3e6eee71b183240 (patch)
tree3eb1b14c85e9cf906f4f41cf4605176b57c1677e
parent210ed0b82e547c79903ee0c3ab59df9b88239ed4 (diff)
parentc8f4732de4a13dab304aec867bf6316f989bca7f (diff)
Merge remote-tracking branch 'origin/users/nfbrown/SLE11-SP4/for-next' into users/mhocko/SLE11-SP4/for-next
-rw-r--r--patches.fixes/NFSv4-Don-t-exit-the-state-manager-without-clearing-.patch45
-rw-r--r--patches.fixes/SUNRPC-Fix-a-potential-race-in-xprt_connect.patch42
-rw-r--r--patches.fixes/fscache-Fix-race-in-fscache_op_complete-due-to-split.patch70
-rw-r--r--series.conf3
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