From c7cadf8ca5eaa9f43f38b040502957a46ec0d8ee Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Sat, 26 Jan 2019 13:26:58 -0500 Subject: [PATCH] patches for 4.20 Signed-off-by: Sasha Levin --- ...fix-the-cockup-in-the-previous-patch.patch | 48 +++++++++++++++++++ queue-4.20/series | 2 + ...erberos-performance-behavior-regress.patch | 45 +++++++++++++++++ 3 files changed, 95 insertions(+) create mode 100644 queue-4.20/arm-fix-the-cockup-in-the-previous-patch.patch create mode 100644 queue-4.20/sunrpc-address-kerberos-performance-behavior-regress.patch 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 index 00000000000..668782d0880 --- /dev/null +++ b/queue-4.20/arm-fix-the-cockup-in-the-previous-patch.patch @@ -0,0 +1,48 @@ +From 0249e3e9fb145b0b7ec9c71ae93ef22867992099 Mon Sep 17 00:00:00 2001 +From: Russell King +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 +Signed-off-by: David A. Long +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.20/series b/queue-4.20/series index 186abb90116..c2f2b7426f2 100644 --- a/queue-4.20/series +++ b/queue-4.20/series @@ -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 index 00000000000..aad73c8468d --- /dev/null +++ b/queue-4.20/sunrpc-address-kerberos-performance-behavior-regress.patch @@ -0,0 +1,45 @@ +From 7214a6bc51523e25cc196be25fd1679aebe7bf9c Mon Sep 17 00:00:00 2001 +From: Chuck Lever +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 +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + 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 + -- 2.47.2