--- /dev/null
+From 90444b958461a5f8fc299ece0fe17eab15cba1e1 Mon Sep 17 00:00:00 2001
+From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Date: Wed, 15 Apr 2020 16:42:33 +0200
+Subject: ARM: dts: bcm283x: Disable dsi0 node
+
+From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+
+commit 90444b958461a5f8fc299ece0fe17eab15cba1e1 upstream.
+
+Since its inception the module was meant to be disabled by default, but
+the original commit failed to add the relevant property.
+
+Fixes: 4aba4cf82054 ("ARM: dts: bcm2835: Add the DSI module nodes and clocks")
+Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Reviewed-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/bcm283x.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm/boot/dts/bcm283x.dtsi
++++ b/arch/arm/boot/dts/bcm283x.dtsi
+@@ -476,6 +476,7 @@
+ "dsi0_ddr2",
+ "dsi0_ddr";
+
++ status = "disabled";
+ };
+
+ thermal: thermal@7e212000 {
--- /dev/null
+From 5fa9a98fb10380e48a398998cd36a85e4ef711d6 Mon Sep 17 00:00:00 2001
+From: Luke Nelson <lukenels@cs.washington.edu>
+Date: Wed, 22 Apr 2020 10:36:29 -0700
+Subject: bpf, x86_32: Fix incorrect encoding in BPF_LDX zero-extension
+
+From: Luke Nelson <lukenels@cs.washington.edu>
+
+commit 5fa9a98fb10380e48a398998cd36a85e4ef711d6 upstream.
+
+The current JIT uses the following sequence to zero-extend into the
+upper 32 bits of the destination register for BPF_LDX BPF_{B,H,W},
+when the destination register is not on the stack:
+
+ EMIT3(0xC7, add_1reg(0xC0, dst_hi), 0);
+
+The problem is that C7 /0 encodes a MOV instruction that requires a 4-byte
+immediate; the current code emits only 1 byte of the immediate. This
+means that the first 3 bytes of the next instruction will be treated as
+the rest of the immediate, breaking the stream of instructions.
+
+This patch fixes the problem by instead emitting "xor dst_hi,dst_hi"
+to clear the upper 32 bits. This fixes the problem and is more efficient
+than using MOV to load a zero immediate.
+
+This bug may not be currently triggerable as BPF_REG_AX is the only
+register not stored on the stack and the verifier uses it in a limited
+way, and the verifier implements a zero-extension optimization. But the
+JIT should avoid emitting incorrect encodings regardless.
+
+Fixes: 03f5781be2c7b ("bpf, x86_32: add eBPF JIT compiler for ia32")
+Signed-off-by: Xi Wang <xi.wang@gmail.com>
+Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com>
+Acked-by: Wang YanQing <udknight@gmail.com>
+Link: https://lore.kernel.org/bpf/20200422173630.8351-1-luke.r.nels@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/net/bpf_jit_comp32.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/net/bpf_jit_comp32.c
++++ b/arch/x86/net/bpf_jit_comp32.c
+@@ -1830,7 +1830,9 @@ static int do_jit(struct bpf_prog *bpf_p
+ STACK_VAR(dst_hi));
+ EMIT(0x0, 4);
+ } else {
+- EMIT3(0xC7, add_1reg(0xC0, dst_hi), 0);
++ /* xor dst_hi,dst_hi */
++ EMIT2(0x33,
++ add_2reg(0xC0, dst_hi, dst_hi));
+ }
+ break;
+ case BPF_DW:
--- /dev/null
+From bc23d0e3f717ced21fbfacab3ab887d55e5ba367 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= <toke@redhat.com>
+Date: Thu, 16 Apr 2020 10:31:20 +0200
+Subject: cpumap: Avoid warning when CONFIG_DEBUG_PER_CPU_MAPS is enabled
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Toke Høiland-Jørgensen <toke@redhat.com>
+
+commit bc23d0e3f717ced21fbfacab3ab887d55e5ba367 upstream.
+
+When the kernel is built with CONFIG_DEBUG_PER_CPU_MAPS, the cpumap code
+can trigger a spurious warning if CONFIG_CPUMASK_OFFSTACK is also set. This
+happens because in this configuration, NR_CPUS can be larger than
+nr_cpumask_bits, so the initial check in cpu_map_alloc() is not sufficient
+to guard against hitting the warning in cpumask_check().
+
+Fix this by explicitly checking the supplied key against the
+nr_cpumask_bits variable before calling cpu_possible().
+
+Fixes: 6710e1126934 ("bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP")
+Reported-by: Xiumei Mu <xmu@redhat.com>
+Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Tested-by: Xiumei Mu <xmu@redhat.com>
+Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
+Acked-by: Song Liu <songliubraving@fb.com>
+Link: https://lore.kernel.org/bpf/20200416083120.453718-1-toke@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/bpf/cpumap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/bpf/cpumap.c
++++ b/kernel/bpf/cpumap.c
+@@ -455,7 +455,7 @@ static int cpu_map_update_elem(struct bp
+ return -EOVERFLOW;
+
+ /* Make sure CPU is a valid possible cpu */
+- if (!cpu_possible(key_cpu))
++ if (key_cpu >= nr_cpumask_bits || !cpu_possible(key_cpu))
+ return -ENODEV;
+
+ if (qsize == 0) {
--- /dev/null
+From a019b36123aec9700b21ae0724710f62928a8bc1 Mon Sep 17 00:00:00 2001
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+Date: Thu, 9 Apr 2020 09:46:20 +0200
+Subject: net/mlx5: Fix failing fw tracer allocation on s390
+
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+
+commit a019b36123aec9700b21ae0724710f62928a8bc1 upstream.
+
+On s390 FORCE_MAX_ZONEORDER is 9 instead of 11, thus a larger kzalloc()
+allocation as done for the firmware tracer will always fail.
+
+Looking at mlx5_fw_tracer_save_trace(), it is actually the driver itself
+that copies the debug data into the trace array and there is no need for
+the allocation to be contiguous in physical memory. We can therefor use
+kvzalloc() instead of kzalloc() and get rid of the large contiguous
+allcoation.
+
+Fixes: f53aaa31cce7 ("net/mlx5: FW tracer, implement tracer logic")
+Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
+Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
+@@ -796,7 +796,7 @@ struct mlx5_fw_tracer *mlx5_fw_tracer_cr
+ return NULL;
+ }
+
+- tracer = kzalloc(sizeof(*tracer), GFP_KERNEL);
++ tracer = kvzalloc(sizeof(*tracer), GFP_KERNEL);
+ if (!tracer)
+ return ERR_PTR(-ENOMEM);
+
+@@ -842,7 +842,7 @@ destroy_workqueue:
+ tracer->dev = NULL;
+ destroy_workqueue(tracer->work_queue);
+ free_tracer:
+- kfree(tracer);
++ kvfree(tracer);
+ return ERR_PTR(err);
+ }
+
+@@ -919,7 +919,7 @@ void mlx5_fw_tracer_destroy(struct mlx5_
+ mlx5_fw_tracer_destroy_log_buf(tracer);
+ flush_workqueue(tracer->work_queue);
+ destroy_workqueue(tracer->work_queue);
+- kfree(tracer);
++ kvfree(tracer);
+ }
+
+ void mlx5_fw_tracer_event(struct mlx5_core_dev *dev, struct mlx5_eqe *eqe)
--- /dev/null
+From 299bd044a6f332b4a6c8f708575c27cad70a35c1 Mon Sep 17 00:00:00 2001
+From: Raymond Pang <RaymondPang-oc@zhaoxin.com>
+Date: Fri, 27 Mar 2020 17:11:48 +0800
+Subject: PCI: Add ACS quirk for Zhaoxin Root/Downstream Ports
+
+From: Raymond Pang <RaymondPang-oc@zhaoxin.com>
+
+commit 299bd044a6f332b4a6c8f708575c27cad70a35c1 upstream.
+
+Many Zhaoxin Root Ports and Switch Downstream Ports do provide ACS-like
+capability but have no ACS Capability Structure. Peer-to-Peer transactions
+could be blocked between these ports, so add quirk so devices behind them
+could be assigned to different IOMMU group.
+
+Link: https://lore.kernel.org/r/20200327091148.5190-4-RaymondPang-oc@zhaoxin.com
+Signed-off-by: Raymond Pang <RaymondPang-oc@zhaoxin.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/quirks.c | 25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -4424,6 +4424,29 @@ static int pci_quirk_intel_pch_acs(struc
+ }
+
+ /*
++ * Many Zhaoxin Root Ports and Switch Downstream Ports have no ACS capability.
++ * But the implementation could block peer-to-peer transactions between them
++ * and provide ACS-like functionality.
++ */
++static int pci_quirk_zhaoxin_pcie_ports_acs(struct pci_dev *dev, u16 acs_flags)
++{
++ if (!pci_is_pcie(dev) ||
++ ((pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT) &&
++ (pci_pcie_type(dev) != PCI_EXP_TYPE_DOWNSTREAM)))
++ return -ENOTTY;
++
++ switch (dev->device) {
++ case 0x0710 ... 0x071e:
++ case 0x0721:
++ case 0x0723 ... 0x0732:
++ return pci_acs_ctrl_enabled(acs_flags,
++ PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF);
++ }
++
++ return false;
++}
++
++/*
+ * These QCOM root ports do provide ACS-like features to disable peer
+ * transactions and validate bus numbers in requests, but do not provide an
+ * actual PCIe ACS capability. Hardware supports source validation but it
+@@ -4634,6 +4657,8 @@ static const struct pci_dev_acs_enabled
+ { PCI_VENDOR_ID_AMPERE, 0xE00A, pci_quirk_xgene_acs },
+ { PCI_VENDOR_ID_AMPERE, 0xE00B, pci_quirk_xgene_acs },
+ { PCI_VENDOR_ID_AMPERE, 0xE00C, pci_quirk_xgene_acs },
++ /* Zhaoxin Root/Downstream Ports */
++ { PCI_VENDOR_ID_ZHAOXIN, PCI_ANY_ID, pci_quirk_zhaoxin_pcie_ports_acs },
+ { 0 }
+ };
+
--- /dev/null
+From 2880325bda8d53566dcb9725abc929eec871608e Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Fri, 20 Dec 2019 03:20:06 +0800
+Subject: PCI: Avoid ASMedia XHCI USB PME# from D0 defect
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit 2880325bda8d53566dcb9725abc929eec871608e upstream.
+
+The ASMedia USB XHCI Controller claims to support generating PME# while
+in D0:
+
+ 01:00.0 USB controller: ASMedia Technology Inc. Device 2142 (prog-if 30 [XHCI])
+ Subsystem: SUNIX Co., Ltd. Device 312b
+ Capabilities: [78] Power Management version 3
+ Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot-,D3cold-)
+ Status: D0 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
+
+However PME# only gets asserted when plugging USB 2.0 or USB 1.1 devices,
+but not for USB 3.0 devices.
+
+Remove PCI_PM_CAP_PME_D0 to avoid using PME under D0.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205919
+Link: https://lore.kernel.org/r/20191219192006.16270-1-kai.heng.feng@canonical.com
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/quirks.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -5282,3 +5282,14 @@ out_disable:
+ DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, 0x13b1,
+ PCI_CLASS_DISPLAY_VGA, 8,
+ quirk_reset_lenovo_thinkpad_p50_nvgpu);
++
++/*
++ * Device [1b21:2142]
++ * When in D0, PME# doesn't get asserted when plugging USB 3.0 device.
++ */
++static void pci_fixup_no_d0_pme(struct pci_dev *dev)
++{
++ pci_info(dev, "PME# does not work under D0, disabling it\n");
++ dev->pme_support &= ~(PCI_PM_CAP_PME_D0 >> PCI_PM_CAP_PME_SHIFT);
++}
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ASMEDIA, 0x2142, pci_fixup_no_d0_pme);
--- /dev/null
+From 0a8f41023e8a3c100b3dc458ed2da651bf961ead Mon Sep 17 00:00:00 2001
+From: Bjorn Helgaas <bhelgaas@google.com>
+Date: Thu, 9 Apr 2020 12:43:45 -0500
+Subject: PCI: Move Apex Edge TPU class quirk to fix BAR assignment
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+commit 0a8f41023e8a3c100b3dc458ed2da651bf961ead upstream.
+
+Some Google Apex Edge TPU devices have a class code of 0
+(PCI_CLASS_NOT_DEFINED). This prevents the PCI core from assigning
+resources for the Apex BARs because __dev_sort_resources() ignores
+classless devices, host bridges, and IOAPICs.
+
+On x86, firmware typically assigns those resources, so this was not a
+problem. But on some architectures, firmware does *not* assign BARs, and
+since the PCI core didn't do it either, the Apex device didn't work
+correctly:
+
+ apex 0000:01:00.0: can't enable device: BAR 0 [mem 0x00000000-0x00003fff 64bit pref] not claimed
+ apex 0000:01:00.0: error enabling PCI device
+
+f390d08d8b87 ("staging: gasket: apex: fixup undefined PCI class") added a
+quirk to fix the class code, but it was in the apex driver, and if the
+driver was built as a module, it was too late to help.
+
+Move the quirk to the PCI core, where it will always run early enough that
+the PCI core will assign resources if necessary.
+
+Link: https://lore.kernel.org/r/CAEzXK1r0Er039iERnc2KJ4jn7ySNUOG9H=Ha8TD8XroVqiZjgg@mail.gmail.com
+Fixes: f390d08d8b87 ("staging: gasket: apex: fixup undefined PCI class")
+Reported-by: Luís Mendes <luis.p.mendes@gmail.com>
+Debugged-by: Luís Mendes <luis.p.mendes@gmail.com>
+Tested-by: Luis Mendes <luis.p.mendes@gmail.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: Todd Poynor <toddpoynor@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/quirks.c | 7 +++++++
+ drivers/staging/gasket/apex_driver.c | 7 -------
+ 2 files changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -5318,3 +5318,10 @@ static void pci_fixup_no_d0_pme(struct p
+ dev->pme_support &= ~(PCI_PM_CAP_PME_D0 >> PCI_PM_CAP_PME_SHIFT);
+ }
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ASMEDIA, 0x2142, pci_fixup_no_d0_pme);
++
++static void apex_pci_fixup_class(struct pci_dev *pdev)
++{
++ pdev->class = (PCI_CLASS_SYSTEM_OTHER << 8) | pdev->class;
++}
++DECLARE_PCI_FIXUP_CLASS_HEADER(0x1ac1, 0x089a,
++ PCI_CLASS_NOT_DEFINED, 8, apex_pci_fixup_class);
+--- a/drivers/staging/gasket/apex_driver.c
++++ b/drivers/staging/gasket/apex_driver.c
+@@ -578,13 +578,6 @@ static const struct pci_device_id apex_p
+ { PCI_DEVICE(APEX_PCI_VENDOR_ID, APEX_PCI_DEVICE_ID) }, { 0 }
+ };
+
+-static void apex_pci_fixup_class(struct pci_dev *pdev)
+-{
+- pdev->class = (PCI_CLASS_SYSTEM_OTHER << 8) | pdev->class;
+-}
+-DECLARE_PCI_FIXUP_CLASS_HEADER(APEX_PCI_VENDOR_ID, APEX_PCI_DEVICE_ID,
+- PCI_CLASS_NOT_DEFINED, 8, apex_pci_fixup_class);
+-
+ static int apex_pci_probe(struct pci_dev *pci_dev,
+ const struct pci_device_id *id)
+ {
--- /dev/null
+From f3bed55e850926614b9898fe982f66d2541a36a5 Mon Sep 17 00:00:00 2001
+From: Ian Rogers <irogers@google.com>
+Date: Fri, 17 Apr 2020 11:28:42 -0700
+Subject: perf/core: fix parent pid/tid in task exit events
+
+From: Ian Rogers <irogers@google.com>
+
+commit f3bed55e850926614b9898fe982f66d2541a36a5 upstream.
+
+Current logic yields the child task as the parent.
+
+Before:
+$ perf record bash -c "perf list > /dev/null"
+$ perf script -D |grep 'FORK\|EXIT'
+4387036190981094 0x5a70 [0x30]: PERF_RECORD_FORK(10472:10472):(10470:10470)
+4387036606207580 0xf050 [0x30]: PERF_RECORD_EXIT(10472:10472):(10472:10472)
+4387036607103839 0x17150 [0x30]: PERF_RECORD_EXIT(10470:10470):(10470:10470)
+ ^
+ Note the repeated values here -------------------/
+
+After:
+383281514043 0x9d8 [0x30]: PERF_RECORD_FORK(2268:2268):(2266:2266)
+383442003996 0x2180 [0x30]: PERF_RECORD_EXIT(2268:2268):(2266:2266)
+383451297778 0xb70 [0x30]: PERF_RECORD_EXIT(2266:2266):(2265:2265)
+
+Fixes: 94d5d1b2d891 ("perf_counter: Report the cloning task as parent on perf_counter_fork()")
+Reported-by: KP Singh <kpsingh@google.com>
+Signed-off-by: Ian Rogers <irogers@google.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Link: https://lkml.kernel.org/r/20200417182842.12522-1-irogers@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/events/core.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/kernel/events/core.c
++++ b/kernel/events/core.c
+@@ -6923,10 +6923,17 @@ static void perf_event_task_output(struc
+ goto out;
+
+ task_event->event_id.pid = perf_event_pid(event, task);
+- task_event->event_id.ppid = perf_event_pid(event, current);
+-
+ task_event->event_id.tid = perf_event_tid(event, task);
+- task_event->event_id.ptid = perf_event_tid(event, current);
++
++ if (task_event->event_id.header.type == PERF_RECORD_EXIT) {
++ task_event->event_id.ppid = perf_event_pid(event,
++ task->real_parent);
++ task_event->event_id.ptid = perf_event_pid(event,
++ task->real_parent);
++ } else { /* PERF_RECORD_FORK */
++ task_event->event_id.ppid = perf_event_pid(event, current);
++ task_event->event_id.ptid = perf_event_tid(event, current);
++ }
+
+ task_event->event_id.time = perf_event_clock(event);
+
rxrpc-fix-data-tx-to-disable-nofrag-for-udp-on-af_inet6-socket.patch
net-cxgb4-check-the-return-from-t4_query_params-properly.patch
xfs-acquire-superblock-freeze-protection-on-eofblocks-scans.patch
+svcrdma-fix-trace-point-use-after-free-race.patch
+svcrdma-fix-leak-of-svc_rdma_recv_ctxt-objects.patch
+pci-avoid-asmedia-xhci-usb-pme-from-d0-defect.patch
+pci-add-acs-quirk-for-zhaoxin-root-downstream-ports.patch
+pci-move-apex-edge-tpu-class-quirk-to-fix-bar-assignment.patch
+arm-dts-bcm283x-disable-dsi0-node.patch
+cpumap-avoid-warning-when-config_debug_per_cpu_maps-is-enabled.patch
+net-mlx5-fix-failing-fw-tracer-allocation-on-s390.patch
+perf-core-fix-parent-pid-tid-in-task-exit-events.patch
+bpf-x86_32-fix-incorrect-encoding-in-bpf_ldx-zero-extension.patch
--- /dev/null
+From 23cf1ee1f1869966b75518c59b5cbda4c6c92450 Mon Sep 17 00:00:00 2001
+From: Chuck Lever <chuck.lever@oracle.com>
+Date: Tue, 31 Mar 2020 17:02:33 -0400
+Subject: svcrdma: Fix leak of svc_rdma_recv_ctxt objects
+
+From: Chuck Lever <chuck.lever@oracle.com>
+
+commit 23cf1ee1f1869966b75518c59b5cbda4c6c92450 upstream.
+
+Utilize the xpo_release_rqst transport method to ensure that each
+rqstp's svc_rdma_recv_ctxt object is released even when the server
+cannot return a Reply for that rqstp.
+
+Without this fix, each RPC whose Reply cannot be sent leaks one
+svc_rdma_recv_ctxt. This is a 2.5KB structure, a 4KB DMA-mapped
+Receive buffer, and any pages that might be part of the Reply
+message.
+
+The leak is infrequent unless the network fabric is unreliable or
+Kerberos is in use, as GSS sequence window overruns, which result
+in connection loss, are more common on fast transports.
+
+Fixes: 3a88092ee319 ("svcrdma: Preserve Receive buffer until svc_rdma_sendto")
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/sunrpc/svc_rdma.h | 1 +
+ net/sunrpc/svc_xprt.c | 3 ---
+ net/sunrpc/svcsock.c | 4 ++++
+ net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 22 ++++++++++++++++++++++
+ net/sunrpc/xprtrdma/svc_rdma_sendto.c | 13 +++----------
+ net/sunrpc/xprtrdma/svc_rdma_transport.c | 5 -----
+ 6 files changed, 30 insertions(+), 18 deletions(-)
+
+--- a/include/linux/sunrpc/svc_rdma.h
++++ b/include/linux/sunrpc/svc_rdma.h
+@@ -159,6 +159,7 @@ extern bool svc_rdma_post_recvs(struct s
+ extern void svc_rdma_recv_ctxt_put(struct svcxprt_rdma *rdma,
+ struct svc_rdma_recv_ctxt *ctxt);
+ extern void svc_rdma_flush_recv_queues(struct svcxprt_rdma *rdma);
++extern void svc_rdma_release_rqst(struct svc_rqst *rqstp);
+ extern int svc_rdma_recvfrom(struct svc_rqst *);
+
+ /* svc_rdma_rw.c */
+--- a/net/sunrpc/svc_xprt.c
++++ b/net/sunrpc/svc_xprt.c
+@@ -878,9 +878,6 @@ int svc_send(struct svc_rqst *rqstp)
+ if (!xprt)
+ goto out;
+
+- /* release the receive skb before sending the reply */
+- xprt->xpt_ops->xpo_release_rqst(rqstp);
+-
+ /* calculate over-all length */
+ xb = &rqstp->rq_res;
+ xb->len = xb->head[0].iov_len +
+--- a/net/sunrpc/svcsock.c
++++ b/net/sunrpc/svcsock.c
+@@ -636,6 +636,8 @@ svc_udp_sendto(struct svc_rqst *rqstp)
+ {
+ int error;
+
++ svc_release_udp_skb(rqstp);
++
+ error = svc_sendto(rqstp, &rqstp->rq_res);
+ if (error == -ECONNREFUSED)
+ /* ICMP error on earlier request. */
+@@ -1173,6 +1175,8 @@ static int svc_tcp_sendto(struct svc_rqs
+ int sent;
+ __be32 reclen;
+
++ svc_release_skb(rqstp);
++
+ /* Set up the first element of the reply kvec.
+ * Any other kvecs that may be in use have been taken
+ * care of by the server implementation itself.
+--- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
++++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
+@@ -226,6 +226,26 @@ void svc_rdma_recv_ctxt_put(struct svcxp
+ svc_rdma_recv_ctxt_destroy(rdma, ctxt);
+ }
+
++/**
++ * svc_rdma_release_rqst - Release transport-specific per-rqst resources
++ * @rqstp: svc_rqst being released
++ *
++ * Ensure that the recv_ctxt is released whether or not a Reply
++ * was sent. For example, the client could close the connection,
++ * or svc_process could drop an RPC, before the Reply is sent.
++ */
++void svc_rdma_release_rqst(struct svc_rqst *rqstp)
++{
++ struct svc_rdma_recv_ctxt *ctxt = rqstp->rq_xprt_ctxt;
++ struct svc_xprt *xprt = rqstp->rq_xprt;
++ struct svcxprt_rdma *rdma =
++ container_of(xprt, struct svcxprt_rdma, sc_xprt);
++
++ rqstp->rq_xprt_ctxt = NULL;
++ if (ctxt)
++ svc_rdma_recv_ctxt_put(rdma, ctxt);
++}
++
+ static int __svc_rdma_post_recv(struct svcxprt_rdma *rdma,
+ struct svc_rdma_recv_ctxt *ctxt)
+ {
+@@ -704,6 +724,8 @@ int svc_rdma_recvfrom(struct svc_rqst *r
+ __be32 *p;
+ int ret;
+
++ rqstp->rq_xprt_ctxt = NULL;
++
+ spin_lock(&rdma_xprt->sc_rq_dto_lock);
+ ctxt = svc_rdma_next_recv_ctxt(&rdma_xprt->sc_read_complete_q);
+ if (ctxt) {
+--- a/net/sunrpc/xprtrdma/svc_rdma_sendto.c
++++ b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
+@@ -908,12 +908,7 @@ int svc_rdma_sendto(struct svc_rqst *rqs
+ wr_lst, rp_ch);
+ if (ret < 0)
+ goto err1;
+- ret = 0;
+-
+-out:
+- rqstp->rq_xprt_ctxt = NULL;
+- svc_rdma_recv_ctxt_put(rdma, rctxt);
+- return ret;
++ return 0;
+
+ err2:
+ if (ret != -E2BIG && ret != -EINVAL)
+@@ -922,14 +917,12 @@ out:
+ ret = svc_rdma_send_error_msg(rdma, sctxt, rqstp);
+ if (ret < 0)
+ goto err1;
+- ret = 0;
+- goto out;
++ return 0;
+
+ err1:
+ svc_rdma_send_ctxt_put(rdma, sctxt);
+ err0:
+ trace_svcrdma_send_failed(rqstp, ret);
+ set_bit(XPT_CLOSE, &xprt->xpt_flags);
+- ret = -ENOTCONN;
+- goto out;
++ return -ENOTCONN;
+ }
+--- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
++++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
+@@ -71,7 +71,6 @@ static struct svc_xprt *svc_rdma_create(
+ struct sockaddr *sa, int salen,
+ int flags);
+ static struct svc_xprt *svc_rdma_accept(struct svc_xprt *xprt);
+-static void svc_rdma_release_rqst(struct svc_rqst *);
+ static void svc_rdma_detach(struct svc_xprt *xprt);
+ static void svc_rdma_free(struct svc_xprt *xprt);
+ static int svc_rdma_has_wspace(struct svc_xprt *xprt);
+@@ -616,10 +615,6 @@ static struct svc_xprt *svc_rdma_accept(
+ return NULL;
+ }
+
+-static void svc_rdma_release_rqst(struct svc_rqst *rqstp)
+-{
+-}
+-
+ /*
+ * When connected, an svc_xprt has at least two references:
+ *
--- /dev/null
+From e28b4fc652c1830796a4d3e09565f30c20f9a2cf Mon Sep 17 00:00:00 2001
+From: Chuck Lever <chuck.lever@oracle.com>
+Date: Mon, 30 Mar 2020 14:27:37 -0400
+Subject: svcrdma: Fix trace point use-after-free race
+
+From: Chuck Lever <chuck.lever@oracle.com>
+
+commit e28b4fc652c1830796a4d3e09565f30c20f9a2cf upstream.
+
+I hit this while testing nfsd-5.7 with kernel memory debugging
+enabled on my server:
+
+Mar 30 13:21:45 klimt kernel: BUG: unable to handle page fault for address: ffff8887e6c279a8
+Mar 30 13:21:45 klimt kernel: #PF: supervisor read access in kernel mode
+Mar 30 13:21:45 klimt kernel: #PF: error_code(0x0000) - not-present page
+Mar 30 13:21:45 klimt kernel: PGD 3601067 P4D 3601067 PUD 87c519067 PMD 87c3e2067 PTE 800ffff8193d8060
+Mar 30 13:21:45 klimt kernel: Oops: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
+Mar 30 13:21:45 klimt kernel: CPU: 2 PID: 1933 Comm: nfsd Not tainted 5.6.0-rc6-00040-g881e87a3c6f9 #1591
+Mar 30 13:21:45 klimt kernel: Hardware name: Supermicro Super Server/X10SRL-F, BIOS 1.0c 09/09/2015
+Mar 30 13:21:45 klimt kernel: RIP: 0010:svc_rdma_post_chunk_ctxt+0xab/0x284 [rpcrdma]
+Mar 30 13:21:45 klimt kernel: Code: c1 83 34 02 00 00 29 d0 85 c0 7e 72 48 8b bb a0 02 00 00 48 8d 54 24 08 4c 89 e6 48 8b 07 48 8b 40 20 e8 5a 5c 2b e1 41 89 c6 <8b> 45 20 89 44 24 04 8b 05 02 e9 01 00 85 c0 7e 33 e9 5e 01 00 00
+Mar 30 13:21:45 klimt kernel: RSP: 0018:ffffc90000dfbdd8 EFLAGS: 00010286
+Mar 30 13:21:45 klimt kernel: RAX: 0000000000000000 RBX: ffff8887db8db400 RCX: 0000000000000030
+Mar 30 13:21:45 klimt kernel: RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000246
+Mar 30 13:21:45 klimt kernel: RBP: ffff8887e6c27988 R08: 0000000000000000 R09: 0000000000000004
+Mar 30 13:21:45 klimt kernel: R10: ffffc90000dfbdd8 R11: 00c068ef00000000 R12: ffff8887eb4e4a80
+Mar 30 13:21:45 klimt kernel: R13: ffff8887db8db634 R14: 0000000000000000 R15: ffff8887fc931000
+Mar 30 13:21:45 klimt kernel: FS: 0000000000000000(0000) GS:ffff88885bd00000(0000) knlGS:0000000000000000
+Mar 30 13:21:45 klimt kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+Mar 30 13:21:45 klimt kernel: CR2: ffff8887e6c279a8 CR3: 000000081b72e002 CR4: 00000000001606e0
+Mar 30 13:21:45 klimt kernel: Call Trace:
+Mar 30 13:21:45 klimt kernel: ? svc_rdma_vec_to_sg+0x7f/0x7f [rpcrdma]
+Mar 30 13:21:45 klimt kernel: svc_rdma_send_write_chunk+0x59/0xce [rpcrdma]
+Mar 30 13:21:45 klimt kernel: svc_rdma_sendto+0xf9/0x3ae [rpcrdma]
+Mar 30 13:21:45 klimt kernel: ? nfsd_destroy+0x51/0x51 [nfsd]
+Mar 30 13:21:45 klimt kernel: svc_send+0x105/0x1e3 [sunrpc]
+Mar 30 13:21:45 klimt kernel: nfsd+0xf2/0x149 [nfsd]
+Mar 30 13:21:45 klimt kernel: kthread+0xf6/0xfb
+Mar 30 13:21:45 klimt kernel: ? kthread_queue_delayed_work+0x74/0x74
+Mar 30 13:21:45 klimt kernel: ret_from_fork+0x3a/0x50
+Mar 30 13:21:45 klimt kernel: Modules linked in: ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue ib_umad ib_ipoib mlx4_ib sb_edac x86_pkg_temp_thermal iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel glue_helper crypto_simd cryptd pcspkr rpcrdma i2c_i801 rdma_ucm lpc_ich mfd_core ib_iser rdma_cm iw_cm ib_cm mei_me raid0 libiscsi mei sg scsi_transport_iscsi ioatdma wmi ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter nfsd nfs_acl lockd auth_rpcgss grace sunrpc ip_tables xfs libcrc32c mlx4_en sd_mod sr_mod cdrom mlx4_core crc32c_intel igb nvme i2c_algo_bit ahci i2c_core libahci nvme_core dca libata t10_pi qedr dm_mirror dm_region_hash dm_log dm_mod dax qede qed crc8 ib_uverbs ib_core
+Mar 30 13:21:45 klimt kernel: CR2: ffff8887e6c279a8
+Mar 30 13:21:45 klimt kernel: ---[ end trace 87971d2ad3429424 ]---
+
+It's absolutely not safe to use resources pointed to by the @send_wr
+argument of ib_post_send() _after_ that function returns. Those
+resources are typically freed by the Send completion handler, which
+can run before ib_post_send() returns.
+
+Thus the trace points currently around ib_post_send() in the
+server's RPC/RDMA transport are a hazard, even when they are
+disabled. Rearrange them so that they touch the Work Request only
+_before_ ib_post_send() is invoked.
+
+Fixes: bd2abef33394 ("svcrdma: Trace key RDMA API events")
+Fixes: 4201c7464753 ("svcrdma: Introduce svc_rdma_send_ctxt")
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/trace/events/rpcrdma.h | 50 ++++++++++++++++++++++++----------
+ net/sunrpc/xprtrdma/svc_rdma_rw.c | 3 --
+ net/sunrpc/xprtrdma/svc_rdma_sendto.c | 16 ++++++----
+ 3 files changed, 46 insertions(+), 23 deletions(-)
+
+--- a/include/trace/events/rpcrdma.h
++++ b/include/trace/events/rpcrdma.h
+@@ -1322,17 +1322,15 @@ DECLARE_EVENT_CLASS(svcrdma_sendcomp_eve
+
+ TRACE_EVENT(svcrdma_post_send,
+ TP_PROTO(
+- const struct ib_send_wr *wr,
+- int status
++ const struct ib_send_wr *wr
+ ),
+
+- TP_ARGS(wr, status),
++ TP_ARGS(wr),
+
+ TP_STRUCT__entry(
+ __field(const void *, cqe)
+ __field(unsigned int, num_sge)
+ __field(u32, inv_rkey)
+- __field(int, status)
+ ),
+
+ TP_fast_assign(
+@@ -1340,12 +1338,11 @@ TRACE_EVENT(svcrdma_post_send,
+ __entry->num_sge = wr->num_sge;
+ __entry->inv_rkey = (wr->opcode == IB_WR_SEND_WITH_INV) ?
+ wr->ex.invalidate_rkey : 0;
+- __entry->status = status;
+ ),
+
+- TP_printk("cqe=%p num_sge=%u inv_rkey=0x%08x status=%d",
++ TP_printk("cqe=%p num_sge=%u inv_rkey=0x%08x",
+ __entry->cqe, __entry->num_sge,
+- __entry->inv_rkey, __entry->status
++ __entry->inv_rkey
+ )
+ );
+
+@@ -1410,26 +1407,23 @@ TRACE_EVENT(svcrdma_wc_receive,
+ TRACE_EVENT(svcrdma_post_rw,
+ TP_PROTO(
+ const void *cqe,
+- int sqecount,
+- int status
++ int sqecount
+ ),
+
+- TP_ARGS(cqe, sqecount, status),
++ TP_ARGS(cqe, sqecount),
+
+ TP_STRUCT__entry(
+ __field(const void *, cqe)
+ __field(int, sqecount)
+- __field(int, status)
+ ),
+
+ TP_fast_assign(
+ __entry->cqe = cqe;
+ __entry->sqecount = sqecount;
+- __entry->status = status;
+ ),
+
+- TP_printk("cqe=%p sqecount=%d status=%d",
+- __entry->cqe, __entry->sqecount, __entry->status
++ TP_printk("cqe=%p sqecount=%d",
++ __entry->cqe, __entry->sqecount
+ )
+ );
+
+@@ -1525,6 +1519,34 @@ DECLARE_EVENT_CLASS(svcrdma_sendqueue_ev
+ DEFINE_SQ_EVENT(full);
+ DEFINE_SQ_EVENT(retry);
+
++TRACE_EVENT(svcrdma_sq_post_err,
++ TP_PROTO(
++ const struct svcxprt_rdma *rdma,
++ int status
++ ),
++
++ TP_ARGS(rdma, status),
++
++ TP_STRUCT__entry(
++ __field(int, avail)
++ __field(int, depth)
++ __field(int, status)
++ __string(addr, rdma->sc_xprt.xpt_remotebuf)
++ ),
++
++ TP_fast_assign(
++ __entry->avail = atomic_read(&rdma->sc_sq_avail);
++ __entry->depth = rdma->sc_sq_depth;
++ __entry->status = status;
++ __assign_str(addr, rdma->sc_xprt.xpt_remotebuf);
++ ),
++
++ TP_printk("addr=%s sc_sq_avail=%d/%d status=%d",
++ __get_str(addr), __entry->avail, __entry->depth,
++ __entry->status
++ )
++);
++
+ #endif /* _TRACE_RPCRDMA_H */
+
+ #include <trace/define_trace.h>
+--- a/net/sunrpc/xprtrdma/svc_rdma_rw.c
++++ b/net/sunrpc/xprtrdma/svc_rdma_rw.c
+@@ -331,8 +331,6 @@ static int svc_rdma_post_chunk_ctxt(stru
+ if (atomic_sub_return(cc->cc_sqecount,
+ &rdma->sc_sq_avail) > 0) {
+ ret = ib_post_send(rdma->sc_qp, first_wr, &bad_wr);
+- trace_svcrdma_post_rw(&cc->cc_cqe,
+- cc->cc_sqecount, ret);
+ if (ret)
+ break;
+ return 0;
+@@ -345,6 +343,7 @@ static int svc_rdma_post_chunk_ctxt(stru
+ trace_svcrdma_sq_retry(rdma);
+ } while (1);
+
++ trace_svcrdma_sq_post_err(rdma, ret);
+ set_bit(XPT_CLOSE, &xprt->xpt_flags);
+
+ /* If even one was posted, there will be a completion. */
+--- a/net/sunrpc/xprtrdma/svc_rdma_sendto.c
++++ b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
+@@ -310,15 +310,17 @@ int svc_rdma_send(struct svcxprt_rdma *r
+ }
+
+ svc_xprt_get(&rdma->sc_xprt);
++ trace_svcrdma_post_send(wr);
+ ret = ib_post_send(rdma->sc_qp, wr, NULL);
+- trace_svcrdma_post_send(wr, ret);
+- if (ret) {
+- set_bit(XPT_CLOSE, &rdma->sc_xprt.xpt_flags);
+- svc_xprt_put(&rdma->sc_xprt);
+- wake_up(&rdma->sc_send_wait);
+- }
+- break;
++ if (ret)
++ break;
++ return 0;
+ }
++
++ trace_svcrdma_sq_post_err(rdma, ret);
++ set_bit(XPT_CLOSE, &rdma->sc_xprt.xpt_flags);
++ svc_xprt_put(&rdma->sc_xprt);
++ wake_up(&rdma->sc_send_wait);
+ return ret;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
