From: Greg Kroah-Hartman Date: Thu, 30 Apr 2020 15:09:17 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v5.4.37~33 X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=d2fc7d3e4909c0551b168e5f13e1a35da015f87a;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: arm-dts-bcm283x-disable-dsi0-node.patch bpf-x86_32-fix-incorrect-encoding-in-bpf_ldx-zero-extension.patch cpumap-avoid-warning-when-config_debug_per_cpu_maps-is-enabled.patch net-mlx5-fix-failing-fw-tracer-allocation-on-s390.patch pci-add-acs-quirk-for-zhaoxin-root-downstream-ports.patch pci-avoid-asmedia-xhci-usb-pme-from-d0-defect.patch pci-move-apex-edge-tpu-class-quirk-to-fix-bar-assignment.patch perf-core-fix-parent-pid-tid-in-task-exit-events.patch svcrdma-fix-leak-of-svc_rdma_recv_ctxt-objects.patch svcrdma-fix-trace-point-use-after-free-race.patch --- diff --git a/queue-4.19/arm-dts-bcm283x-disable-dsi0-node.patch b/queue-4.19/arm-dts-bcm283x-disable-dsi0-node.patch new file mode 100644 index 00000000000..43f71c4e36e --- /dev/null +++ b/queue-4.19/arm-dts-bcm283x-disable-dsi0-node.patch @@ -0,0 +1,32 @@ +From 90444b958461a5f8fc299ece0fe17eab15cba1e1 Mon Sep 17 00:00:00 2001 +From: Nicolas Saenz Julienne +Date: Wed, 15 Apr 2020 16:42:33 +0200 +Subject: ARM: dts: bcm283x: Disable dsi0 node + +From: Nicolas Saenz Julienne + +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 +Reviewed-by: Eric Anholt +Signed-off-by: Florian Fainelli +Signed-off-by: Greg Kroah-Hartman + +--- + 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 { diff --git a/queue-4.19/bpf-x86_32-fix-incorrect-encoding-in-bpf_ldx-zero-extension.patch b/queue-4.19/bpf-x86_32-fix-incorrect-encoding-in-bpf_ldx-zero-extension.patch new file mode 100644 index 00000000000..f72fed059b2 --- /dev/null +++ b/queue-4.19/bpf-x86_32-fix-incorrect-encoding-in-bpf_ldx-zero-extension.patch @@ -0,0 +1,55 @@ +From 5fa9a98fb10380e48a398998cd36a85e4ef711d6 Mon Sep 17 00:00:00 2001 +From: Luke Nelson +Date: Wed, 22 Apr 2020 10:36:29 -0700 +Subject: bpf, x86_32: Fix incorrect encoding in BPF_LDX zero-extension + +From: Luke Nelson + +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 +Signed-off-by: Luke Nelson +Signed-off-by: Alexei Starovoitov +Reviewed-by: H. Peter Anvin (Intel) +Acked-by: Wang YanQing +Link: https://lore.kernel.org/bpf/20200422173630.8351-1-luke.r.nels@gmail.com +Signed-off-by: Greg Kroah-Hartman + +--- + 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: diff --git a/queue-4.19/cpumap-avoid-warning-when-config_debug_per_cpu_maps-is-enabled.patch b/queue-4.19/cpumap-avoid-warning-when-config_debug_per_cpu_maps-is-enabled.patch new file mode 100644 index 00000000000..994a2d66b7c --- /dev/null +++ b/queue-4.19/cpumap-avoid-warning-when-config_debug_per_cpu_maps-is-enabled.patch @@ -0,0 +1,46 @@ +From bc23d0e3f717ced21fbfacab3ab887d55e5ba367 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= +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 + +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 +Signed-off-by: Toke Høiland-Jørgensen +Signed-off-by: Alexei Starovoitov +Tested-by: Xiumei Mu +Acked-by: Jesper Dangaard Brouer +Acked-by: Song Liu +Link: https://lore.kernel.org/bpf/20200416083120.453718-1-toke@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + 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) { diff --git a/queue-4.19/net-mlx5-fix-failing-fw-tracer-allocation-on-s390.patch b/queue-4.19/net-mlx5-fix-failing-fw-tracer-allocation-on-s390.patch new file mode 100644 index 00000000000..5081f5a47be --- /dev/null +++ b/queue-4.19/net-mlx5-fix-failing-fw-tracer-allocation-on-s390.patch @@ -0,0 +1,56 @@ +From a019b36123aec9700b21ae0724710f62928a8bc1 Mon Sep 17 00:00:00 2001 +From: Niklas Schnelle +Date: Thu, 9 Apr 2020 09:46:20 +0200 +Subject: net/mlx5: Fix failing fw tracer allocation on s390 + +From: Niklas Schnelle + +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 +Signed-off-by: Saeed Mahameed +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.19/pci-add-acs-quirk-for-zhaoxin-root-downstream-ports.patch b/queue-4.19/pci-add-acs-quirk-for-zhaoxin-root-downstream-ports.patch new file mode 100644 index 00000000000..4ed2ef62d2f --- /dev/null +++ b/queue-4.19/pci-add-acs-quirk-for-zhaoxin-root-downstream-ports.patch @@ -0,0 +1,64 @@ +From 299bd044a6f332b4a6c8f708575c27cad70a35c1 Mon Sep 17 00:00:00 2001 +From: Raymond Pang +Date: Fri, 27 Mar 2020 17:11:48 +0800 +Subject: PCI: Add ACS quirk for Zhaoxin Root/Downstream Ports + +From: Raymond Pang + +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 +Signed-off-by: Bjorn Helgaas +Signed-off-by: Greg Kroah-Hartman + +--- + 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 } + }; + diff --git a/queue-4.19/pci-avoid-asmedia-xhci-usb-pme-from-d0-defect.patch b/queue-4.19/pci-avoid-asmedia-xhci-usb-pme-from-d0-defect.patch new file mode 100644 index 00000000000..be800188564 --- /dev/null +++ b/queue-4.19/pci-avoid-asmedia-xhci-usb-pme-from-d0-defect.patch @@ -0,0 +1,50 @@ +From 2880325bda8d53566dcb9725abc929eec871608e Mon Sep 17 00:00:00 2001 +From: Kai-Heng Feng +Date: Fri, 20 Dec 2019 03:20:06 +0800 +Subject: PCI: Avoid ASMedia XHCI USB PME# from D0 defect + +From: Kai-Heng Feng + +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 +Signed-off-by: Bjorn Helgaas +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.19/pci-move-apex-edge-tpu-class-quirk-to-fix-bar-assignment.patch b/queue-4.19/pci-move-apex-edge-tpu-class-quirk-to-fix-bar-assignment.patch new file mode 100644 index 00000000000..7a01b2d5901 --- /dev/null +++ b/queue-4.19/pci-move-apex-edge-tpu-class-quirk-to-fix-bar-assignment.patch @@ -0,0 +1,75 @@ +From 0a8f41023e8a3c100b3dc458ed2da651bf961ead Mon Sep 17 00:00:00 2001 +From: Bjorn Helgaas +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 + +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 +Debugged-by: Luís Mendes +Tested-by: Luis Mendes +Signed-off-by: Bjorn Helgaas +Cc: Todd Poynor +Signed-off-by: Greg Kroah-Hartman + +--- + 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) + { diff --git a/queue-4.19/perf-core-fix-parent-pid-tid-in-task-exit-events.patch b/queue-4.19/perf-core-fix-parent-pid-tid-in-task-exit-events.patch new file mode 100644 index 00000000000..327ee64754a --- /dev/null +++ b/queue-4.19/perf-core-fix-parent-pid-tid-in-task-exit-events.patch @@ -0,0 +1,59 @@ +From f3bed55e850926614b9898fe982f66d2541a36a5 Mon Sep 17 00:00:00 2001 +From: Ian Rogers +Date: Fri, 17 Apr 2020 11:28:42 -0700 +Subject: perf/core: fix parent pid/tid in task exit events + +From: Ian Rogers + +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 +Signed-off-by: Ian Rogers +Signed-off-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/20200417182842.12522-1-irogers@google.com +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-4.19/series b/queue-4.19/series index 47eb000719f..c4333f34e3b 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -13,3 +13,13 @@ i2c-altera-use-proper-variable-to-hold-errno.patch 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 diff --git a/queue-4.19/svcrdma-fix-leak-of-svc_rdma_recv_ctxt-objects.patch b/queue-4.19/svcrdma-fix-leak-of-svc_rdma_recv_ctxt-objects.patch new file mode 100644 index 00000000000..77a06eca2da --- /dev/null +++ b/queue-4.19/svcrdma-fix-leak-of-svc_rdma_recv_ctxt-objects.patch @@ -0,0 +1,169 @@ +From 23cf1ee1f1869966b75518c59b5cbda4c6c92450 Mon Sep 17 00:00:00 2001 +From: Chuck Lever +Date: Tue, 31 Mar 2020 17:02:33 -0400 +Subject: svcrdma: Fix leak of svc_rdma_recv_ctxt objects + +From: Chuck Lever + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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: + * diff --git a/queue-4.19/svcrdma-fix-trace-point-use-after-free-race.patch b/queue-4.19/svcrdma-fix-trace-point-use-after-free-race.patch new file mode 100644 index 00000000000..271f333fd2c --- /dev/null +++ b/queue-4.19/svcrdma-fix-trace-point-use-after-free-race.patch @@ -0,0 +1,214 @@ +From e28b4fc652c1830796a4d3e09565f30c20f9a2cf Mon Sep 17 00:00:00 2001 +From: Chuck Lever +Date: Mon, 30 Mar 2020 14:27:37 -0400 +Subject: svcrdma: Fix trace point use-after-free race + +From: Chuck Lever + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +--- 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; + } +