--- /dev/null
+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
+
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
--- /dev/null
+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
+