]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
patches for 4.20
authorSasha Levin <sashal@kernel.org>
Sat, 26 Jan 2019 18:26:58 +0000 (13:26 -0500)
committerSasha Levin <sashal@kernel.org>
Sat, 26 Jan 2019 18:26:58 +0000 (13:26 -0500)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-4.20/arm-fix-the-cockup-in-the-previous-patch.patch [new file with mode: 0644]
queue-4.20/series
queue-4.20/sunrpc-address-kerberos-performance-behavior-regress.patch [new file with mode: 0644]

diff --git a/queue-4.20/arm-fix-the-cockup-in-the-previous-patch.patch b/queue-4.20/arm-fix-the-cockup-in-the-previous-patch.patch
new file mode 100644 (file)
index 0000000..668782d
--- /dev/null
@@ -0,0 +1,48 @@
+From 0249e3e9fb145b0b7ec9c71ae93ef22867992099 Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@armlinux.org.uk>
+Date: Fri, 25 Jan 2019 17:40:37 -0500
+Subject: ARM: fix the cockup in the previous patch
+
+Commit d6951f582cc50ba0ad22ef46b599740966599b14 upstream.
+
+The intention in the previous patch was to only place the processor
+tables in the .rodata section if big.Little was being built and we
+wanted the branch target hardening, but instead (due to the way it
+was tested) it ended up always placing the tables into the .rodata
+section.
+
+Although harmless, let's correct this anyway.
+
+Fixes: 3a4d0c2172bc ("ARM: ensure that processor vtables is not lost after boot")
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Signed-off-by: David A. Long <dave.long@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/mm/proc-macros.S | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
+index 19516fbc2c55..5461d589a1e2 100644
+--- a/arch/arm/mm/proc-macros.S
++++ b/arch/arm/mm/proc-macros.S
+@@ -278,7 +278,7 @@
+  * If we are building for big.Little with branch predictor hardening,
+  * we need the processor function tables to remain available after boot.
+  */
+-#if 1 // defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
++#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
+       .section ".rodata"
+ #endif
+       .type   \name\()_processor_functions, #object
+@@ -316,7 +316,7 @@ ENTRY(\name\()_processor_functions)
+       .endif
+       .size   \name\()_processor_functions, . - \name\()_processor_functions
+-#if 1 // defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
++#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
+       .previous
+ #endif
+ .endm
+-- 
+2.19.1
+
index 186abb901160146a2f6ef8562699d3e32f0ebb18..c2f2b7426f2091b097a219bd5bb44626cbd67ea8 100644 (file)
@@ -19,3 +19,5 @@ erspan-build-the-header-with-the-right-proto-according-to-erspan_ver.patch
 net-phy-marvell-fix-deadlock-from-wrong-locking.patch
 ip6_gre-update-version-related-info-when-changing-link.patch
 tcp-allow-msg_zerocopy-transmission-also-in-close_wait-state.patch
+arm-fix-the-cockup-in-the-previous-patch.patch
+sunrpc-address-kerberos-performance-behavior-regress.patch
diff --git a/queue-4.20/sunrpc-address-kerberos-performance-behavior-regress.patch b/queue-4.20/sunrpc-address-kerberos-performance-behavior-regress.patch
new file mode 100644 (file)
index 0000000..aad73c8
--- /dev/null
@@ -0,0 +1,45 @@
+From 7214a6bc51523e25cc196be25fd1679aebe7bf9c Mon Sep 17 00:00:00 2001
+From: Chuck Lever <chuck.lever@oracle.com>
+Date: Wed, 9 Jan 2019 10:04:57 -0500
+Subject: SUNRPC: Address Kerberos performance/behavior regression
+
+[ Upstream commit deaa5c96c2f7e8b934088a1e70a0fe8797bd1149 ]
+
+When using Kerberos with v4.20, I've observed frequent connection
+loss on heavy workloads. I traced it down to the client underrunning
+the GSS sequence number window -- NFS servers are required to drop
+the RPC with the low sequence number, and also drop the connection
+to signal that an RPC was dropped.
+
+Bisected to commit 918f3c1fe83c ("SUNRPC: Improve latency for
+interactive tasks").
+
+I've got a one-line workaround for this issue, which is easy to
+backport to v4.20 while a more permanent solution is being derived.
+Essentially, tk_owner-based sorting is disabled for RPCs that carry
+a GSS sequence number.
+
+Fixes: 918f3c1fe83c ("SUNRPC: Improve latency for interactive ... ")
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sunrpc/xprt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
+index 73547d17d3c6..943f08be7c38 100644
+--- a/net/sunrpc/xprt.c
++++ b/net/sunrpc/xprt.c
+@@ -1177,7 +1177,7 @@ xprt_request_enqueue_transmit(struct rpc_task *task)
+                               INIT_LIST_HEAD(&req->rq_xmit2);
+                               goto out;
+                       }
+-              } else {
++              } else if (!req->rq_seqno) {
+                       list_for_each_entry(pos, &xprt->xmit_queue, rq_xmit) {
+                               if (pos->rq_task->tk_owner != task->tk_owner)
+                                       continue;
+-- 
+2.19.1
+