From: Greg Kroah-Hartman Date: Mon, 11 Apr 2022 08:27:20 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v4.9.310~66 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9abdd4a1c3513a663df12c20679622991cb9afa2;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: amd-display-set-backlight-only-if-required.patch arm64-patch_text-fixup-last-cpu-should-be-master.patch ata-sata_dwc_460ex-fix-crash-due-to-oob-write.patch fbdev-fix-unregistering-of-framebuffers-without-device.patch gpio-restrict-usage-of-gpio-chip-irq-members-before-initialization.patch irqchip-gic-v3-fix-gicr_ctlr.rwp-polling.patch perf-core-inherit-event_caps.patch perf-qcom_l2_pmu-fix-an-incorrect-null-check-on-list-iterator.patch perf-x86-intel-don-t-extend-the-pseudo-encoding-to-gp-counters.patch rdma-hfi1-fix-use-after-free-bug-for-mm-struct.patch sunrpc-prevent-immediate-close-reconnect.patch x86-mm-tlb-revert-retpoline-avoidance-approach.patch x86-msi-fix-msi-message-data-shadow-struct.patch --- diff --git a/queue-5.15/amd-display-set-backlight-only-if-required.patch b/queue-5.15/amd-display-set-backlight-only-if-required.patch new file mode 100644 index 00000000000..a9277bdb111 --- /dev/null +++ b/queue-5.15/amd-display-set-backlight-only-if-required.patch @@ -0,0 +1,77 @@ +From 4052287a75eb3fc0f487fcc5f768a38bede455c8 Mon Sep 17 00:00:00 2001 +From: Shirish S +Date: Fri, 11 Mar 2022 20:30:17 +0530 +Subject: amd/display: set backlight only if required + +From: Shirish S + +commit 4052287a75eb3fc0f487fcc5f768a38bede455c8 upstream. + +[Why] +comparing pwm bl values (coverted) with user brightness(converted) +levels in commit_tail leads to continuous setting of backlight via dmub +as they don't to match. +This leads overdrive in queuing of commands to DMCU that sometimes lead +to depending on load on DMCU fw: + +"[drm:dc_dmub_srv_wait_idle] *ERROR* Error waiting for DMUB idle: status=3" + +[How] +Store last successfully set backlight value and compare with it instead +of pwm reads which is not what we should compare with. + +Signed-off-by: Shirish S +Reviewed-by: Harry Wentland +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++++--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 6 ++++++ + 2 files changed, 10 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -3522,7 +3522,7 @@ static u32 convert_brightness_to_user(co + max - min); + } + +-static int amdgpu_dm_backlight_set_level(struct amdgpu_display_manager *dm, ++static void amdgpu_dm_backlight_set_level(struct amdgpu_display_manager *dm, + int bl_idx, + u32 user_brightness) + { +@@ -3550,7 +3550,8 @@ static int amdgpu_dm_backlight_set_level + DRM_DEBUG("DM: Failed to update backlight on eDP[%d]\n", bl_idx); + } + +- return rc ? 0 : 1; ++ if (rc) ++ dm->actual_brightness[bl_idx] = user_brightness; + } + + static int amdgpu_dm_backlight_update_status(struct backlight_device *bd) +@@ -9316,7 +9317,7 @@ static void amdgpu_dm_atomic_commit_tail + /* restore the backlight level */ + for (i = 0; i < dm->num_of_edps; i++) { + if (dm->backlight_dev[i] && +- (amdgpu_dm_backlight_get_level(dm, i) != dm->brightness[i])) ++ (dm->actual_brightness[i] != dm->brightness[i])) + amdgpu_dm_backlight_set_level(dm, i, dm->brightness[i]); + } + #endif +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h +@@ -446,6 +446,12 @@ struct amdgpu_display_manager { + * cached backlight values. + */ + u32 brightness[AMDGPU_DM_MAX_NUM_EDP]; ++ /** ++ * @actual_brightness: ++ * ++ * last successfully applied backlight values. ++ */ ++ u32 actual_brightness[AMDGPU_DM_MAX_NUM_EDP]; + }; + + enum dsc_clock_force_state { diff --git a/queue-5.15/arm64-patch_text-fixup-last-cpu-should-be-master.patch b/queue-5.15/arm64-patch_text-fixup-last-cpu-should-be-master.patch new file mode 100644 index 00000000000..2f7c8bf038b --- /dev/null +++ b/queue-5.15/arm64-patch_text-fixup-last-cpu-should-be-master.patch @@ -0,0 +1,42 @@ +From 31a099dbd91e69fcab55eef4be15ed7a8c984918 Mon Sep 17 00:00:00 2001 +From: Guo Ren +Date: Thu, 7 Apr 2022 15:33:20 +0800 +Subject: arm64: patch_text: Fixup last cpu should be master + +From: Guo Ren + +commit 31a099dbd91e69fcab55eef4be15ed7a8c984918 upstream. + +These patch_text implementations are using stop_machine_cpuslocked +infrastructure with atomic cpu_count. The original idea: When the +master CPU patch_text, the others should wait for it. But current +implementation is using the first CPU as master, which couldn't +guarantee the remaining CPUs are waiting. This patch changes the +last CPU as the master to solve the potential risk. + +Fixes: ae16480785de ("arm64: introduce interfaces to hotpatch kernel and module code") +Signed-off-by: Guo Ren +Signed-off-by: Guo Ren +Reviewed-by: Catalin Marinas +Reviewed-by: Masami Hiramatsu +Cc: +Link: https://lore.kernel.org/r/20220407073323.743224-2-guoren@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/patching.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm64/kernel/patching.c ++++ b/arch/arm64/kernel/patching.c +@@ -117,8 +117,8 @@ static int __kprobes aarch64_insn_patch_ + int i, ret = 0; + struct aarch64_insn_patch *pp = arg; + +- /* The first CPU becomes master */ +- if (atomic_inc_return(&pp->cpu_count) == 1) { ++ /* The last CPU becomes master */ ++ if (atomic_inc_return(&pp->cpu_count) == num_online_cpus()) { + for (i = 0; ret == 0 && i < pp->insn_cnt; i++) + ret = aarch64_insn_patch_text_nosync(pp->text_addrs[i], + pp->new_insns[i]); diff --git a/queue-5.15/ata-sata_dwc_460ex-fix-crash-due-to-oob-write.patch b/queue-5.15/ata-sata_dwc_460ex-fix-crash-due-to-oob-write.patch new file mode 100644 index 00000000000..818bc831b76 --- /dev/null +++ b/queue-5.15/ata-sata_dwc_460ex-fix-crash-due-to-oob-write.patch @@ -0,0 +1,83 @@ +From 7aa8104a554713b685db729e66511b93d989dd6a Mon Sep 17 00:00:00 2001 +From: Christian Lamparter +Date: Sat, 19 Mar 2022 21:11:02 +0100 +Subject: ata: sata_dwc_460ex: Fix crash due to OOB write + +From: Christian Lamparter + +commit 7aa8104a554713b685db729e66511b93d989dd6a upstream. + +the driver uses libata's "tag" values from in various arrays. +Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32, +the value of the SATA_DWC_QCMD_MAX needs to account for that. + +Otherwise ATA_TAG_INTERNAL usage cause similar crashes like +this as reported by Tice Rex on the OpenWrt Forum and +reproduced (with symbols) here: + +| BUG: Kernel NULL pointer dereference at 0x00000000 +| Faulting instruction address: 0xc03ed4b8 +| Oops: Kernel access of bad area, sig: 11 [#1] +| BE PAGE_SIZE=4K PowerPC 44x Platform +| CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0 +| NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c +| REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163) +| MSR: 00021000 CR: 42000222 XER: 00000000 +| DEAR: 00000000 ESR: 00000000 +| GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...] +| [..] +| NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254 +| LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc +| Call Trace: +| [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable) +| [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc +| [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524 +| [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0 +| [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204 +| [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130 +| [...] + +This is because sata_dwc_dma_xfer_complete() NULLs the +dma_pending's next neighbour "chan" (a *dma_chan struct) in +this '32' case right here (line ~735): +> hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE; + +Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes +the NULL'd hsdevp->chan to the dmaengine_slave_config() which then +causes the crash. + +With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1. +This avoids the OOB. But please note, there was a worthwhile discussion +on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not +be a "fake" 33 command-long queue size. + +Ideally, the dw driver should account for the ATA_TAG_INTERNAL. +In Damien Le Moal's words: "... having looked at the driver, it +is a bigger change than just faking a 33rd "tag" that is in fact +not a command tag at all." + +Fixes: 28361c403683c ("libata: add extra internal command") +Cc: stable@kernel.org # 4.18+ +BugLink: https://github.com/openwrt/openwrt/issues/9505 +Signed-off-by: Christian Lamparter +Signed-off-by: Damien Le Moal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/sata_dwc_460ex.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/ata/sata_dwc_460ex.c ++++ b/drivers/ata/sata_dwc_460ex.c +@@ -145,7 +145,11 @@ struct sata_dwc_device { + #endif + }; + +-#define SATA_DWC_QCMD_MAX 32 ++/* ++ * Allow one extra special slot for commands and DMA management ++ * to account for libata internal commands. ++ */ ++#define SATA_DWC_QCMD_MAX (ATA_MAX_QUEUE + 1) + + struct sata_dwc_device_port { + struct sata_dwc_device *hsdev; diff --git a/queue-5.15/fbdev-fix-unregistering-of-framebuffers-without-device.patch b/queue-5.15/fbdev-fix-unregistering-of-framebuffers-without-device.patch new file mode 100644 index 00000000000..744598d0bc3 --- /dev/null +++ b/queue-5.15/fbdev-fix-unregistering-of-framebuffers-without-device.patch @@ -0,0 +1,98 @@ +From 0f525289ff0ddeb380813bd81e0f9bdaaa1c9078 Mon Sep 17 00:00:00 2001 +From: Thomas Zimmermann +Date: Mon, 4 Apr 2022 21:44:02 +0200 +Subject: fbdev: Fix unregistering of framebuffers without device + +From: Thomas Zimmermann + +commit 0f525289ff0ddeb380813bd81e0f9bdaaa1c9078 upstream. + +OF framebuffers do not have an underlying device in the Linux +device hierarchy. Do a regular unregister call instead of hot +unplugging such a non-existing device. Fixes a NULL dereference. +An example error message on ppc64le is shown below. + + BUG: Kernel NULL pointer dereference on read at 0x00000060 + Faulting instruction address: 0xc00000000080dfa4 + Oops: Kernel access of bad area, sig: 11 [#1] + LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries + [...] + CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1 + NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430 + REGS: c000000004132fe0 TRAP: 0300 Not tainted (5.17.0-ae085d7f9365) + MSR: 8000000002009033 CR: 28228282 XER: 20000000 + CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0 + GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029 + GPR04: 00000000ffffefff c000000004132f90 c000000004132f88 0000000000000000 + GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283 + GPR12: 0000000000000000 c00000003fffe300 0000000020000000 0000000000000000 + GPR16: 0000000000000000 0000000113fc4a40 0000000000000005 0000000113fcfb80 + GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0 + GPR24: 0000000000000001 00000000000a0000 c008000000db0168 c0000000021f6ec0 + GPR28: c0000000016d65a8 c000000004b36460 0000000000000000 c0000000016d64b0 + NIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0 + [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable) + [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150 + [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0 + [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm] + [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs] + [...] + [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0 + [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250 + +The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug +firmware fb devices on forced removal"). Most firmware framebuffers +have an underlying platform device, which can be hot-unplugged +before loading the native graphics driver. OF framebuffers do not +(yet) have that device. Fix the code by unregistering the framebuffer +as before without a hot unplug. + +Tested with 5.17 on qemu ppc64le emulation. + +Signed-off-by: Thomas Zimmermann +Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal") +Reported-by: Sudip Mukherjee +Reviewed-by: Daniel Vetter +Reviewed-by: Javier Martinez Canillas +Tested-by: Sudip Mukherjee +Cc: Zack Rusin +Cc: Javier Martinez Canillas +Cc: Hans de Goede +Cc: stable@vger.kernel.org # v5.11+ +Cc: Helge Deller +Cc: Daniel Vetter +Cc: Sam Ravnborg +Cc: Zheyu Ma +Cc: Xiyu Yang +Cc: Zhen Lei +Cc: Matthew Wilcox +Cc: Alex Deucher +Cc: Tetsuo Handa +Cc: Guenter Roeck +Cc: linux-fbdev@vger.kernel.org +Cc: dri-devel@lists.freedesktop.org +Link: https://lore.kernel.org/all/YkHXO6LGHAN0p1pq@debian/ # [1] +Link: https://patchwork.freedesktop.org/patch/msgid/20220404194402.29974-1-tzimmermann@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/video/fbdev/core/fbmem.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/video/fbdev/core/fbmem.c ++++ b/drivers/video/fbdev/core/fbmem.c +@@ -1581,7 +1581,14 @@ static void do_remove_conflicting_frameb + * If it's not a platform device, at least print a warning. A + * fix would add code to remove the device from the system. + */ +- if (dev_is_platform(device)) { ++ if (!device) { ++ /* TODO: Represent each OF framebuffer as its own ++ * device in the device hierarchy. For now, offb ++ * doesn't have such a device, so unregister the ++ * framebuffer as before without warning. ++ */ ++ do_unregister_framebuffer(registered_fb[i]); ++ } else if (dev_is_platform(device)) { + registered_fb[i]->forced_out = true; + platform_device_unregister(to_platform_device(device)); + } else { diff --git a/queue-5.15/gpio-restrict-usage-of-gpio-chip-irq-members-before-initialization.patch b/queue-5.15/gpio-restrict-usage-of-gpio-chip-irq-members-before-initialization.patch new file mode 100644 index 00000000000..eae50b831cc --- /dev/null +++ b/queue-5.15/gpio-restrict-usage-of-gpio-chip-irq-members-before-initialization.patch @@ -0,0 +1,94 @@ +From 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 Mon Sep 17 00:00:00 2001 +From: Shreeya Patel +Date: Mon, 21 Mar 2022 19:02:41 +0530 +Subject: gpio: Restrict usage of GPIO chip irq members before initialization + +From: Shreeya Patel + +commit 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 upstream. + +GPIO chip irq members are exposed before they could be completely +initialized and this leads to race conditions. + +One such issue was observed for the gc->irq.domain variable which +was accessed through the I2C interface in gpiochip_to_irq() before +it could be initialized by gpiochip_add_irqchip(). This resulted in +Kernel NULL pointer dereference. + +Following are the logs for reference :- + +kernel: Call Trace: +kernel: gpiod_to_irq+0x53/0x70 +kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 +kernel: i2c_acpi_get_irq+0xc0/0xd0 +kernel: i2c_device_probe+0x28a/0x2a0 +kernel: really_probe+0xf2/0x460 +kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 + +To avoid such scenarios, restrict usage of GPIO chip irq members before +they are completely initialized. + +Signed-off-by: Shreeya Patel +Cc: stable@vger.kernel.org +Reviewed-by: Andy Shevchenko +Reviewed-by: Linus Walleij +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpiolib.c | 19 +++++++++++++++++++ + include/linux/gpio/driver.h | 9 +++++++++ + 2 files changed, 28 insertions(+) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -1368,6 +1368,16 @@ static int gpiochip_to_irq(struct gpio_c + { + struct irq_domain *domain = gc->irq.domain; + ++#ifdef CONFIG_GPIOLIB_IRQCHIP ++ /* ++ * Avoid race condition with other code, which tries to lookup ++ * an IRQ before the irqchip has been properly registered, ++ * i.e. while gpiochip is still being brought up. ++ */ ++ if (!gc->irq.initialized) ++ return -EPROBE_DEFER; ++#endif ++ + if (!gpiochip_irqchip_irq_valid(gc, offset)) + return -ENXIO; + +@@ -1552,6 +1562,15 @@ static int gpiochip_add_irqchip(struct g + + acpi_gpiochip_request_interrupts(gc); + ++ /* ++ * Using barrier() here to prevent compiler from reordering ++ * gc->irq.initialized before initialization of above ++ * GPIO chip irq members. ++ */ ++ barrier(); ++ ++ gc->irq.initialized = true; ++ + return 0; + } + +--- a/include/linux/gpio/driver.h ++++ b/include/linux/gpio/driver.h +@@ -225,6 +225,15 @@ struct gpio_irq_chip { + unsigned int ngpios); + + /** ++ * @initialized: ++ * ++ * Flag to track GPIO chip irq member's initialization. ++ * This flag will make sure GPIO chip irq members are not used ++ * before they are initialized. ++ */ ++ bool initialized; ++ ++ /** + * @valid_mask: + * + * If not %NULL, holds bitmask of GPIOs which are valid to be included diff --git a/queue-5.15/irqchip-gic-v3-fix-gicr_ctlr.rwp-polling.patch b/queue-5.15/irqchip-gic-v3-fix-gicr_ctlr.rwp-polling.patch new file mode 100644 index 00000000000..20ae1fba63b --- /dev/null +++ b/queue-5.15/irqchip-gic-v3-fix-gicr_ctlr.rwp-polling.patch @@ -0,0 +1,61 @@ +From 0df6664531a12cdd8fc873f0cac0dcb40243d3e9 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Tue, 15 Mar 2022 16:50:32 +0000 +Subject: irqchip/gic-v3: Fix GICR_CTLR.RWP polling + +From: Marc Zyngier + +commit 0df6664531a12cdd8fc873f0cac0dcb40243d3e9 upstream. + +It turns out that our polling of RWP is totally wrong when checking +for it in the redistributors, as we test the *distributor* bit index, +whereas it is a different bit number in the RDs... Oopsie boo. + +This is embarassing. Not only because it is wrong, but also because +it took *8 years* to notice the blunder... + +Just fix the damn thing. + +Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3") +Signed-off-by: Marc Zyngier +Cc: stable@vger.kernel.org +Reviewed-by: Andre Przywara +Reviewed-by: Lorenzo Pieralisi +Link: https://lore.kernel.org/r/20220315165034.794482-2-maz@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-gic-v3.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/irqchip/irq-gic-v3.c ++++ b/drivers/irqchip/irq-gic-v3.c +@@ -206,11 +206,11 @@ static inline void __iomem *gic_dist_bas + } + } + +-static void gic_do_wait_for_rwp(void __iomem *base) ++static void gic_do_wait_for_rwp(void __iomem *base, u32 bit) + { + u32 count = 1000000; /* 1s! */ + +- while (readl_relaxed(base + GICD_CTLR) & GICD_CTLR_RWP) { ++ while (readl_relaxed(base + GICD_CTLR) & bit) { + count--; + if (!count) { + pr_err_ratelimited("RWP timeout, gone fishing\n"); +@@ -224,13 +224,13 @@ static void gic_do_wait_for_rwp(void __i + /* Wait for completion of a distributor change */ + static void gic_dist_wait_for_rwp(void) + { +- gic_do_wait_for_rwp(gic_data.dist_base); ++ gic_do_wait_for_rwp(gic_data.dist_base, GICD_CTLR_RWP); + } + + /* Wait for completion of a redistributor change */ + static void gic_redist_wait_for_rwp(void) + { +- gic_do_wait_for_rwp(gic_data_rdist_rd_base()); ++ gic_do_wait_for_rwp(gic_data_rdist_rd_base(), GICR_CTLR_RWP); + } + + #ifdef CONFIG_ARM64 diff --git a/queue-5.15/perf-core-inherit-event_caps.patch b/queue-5.15/perf-core-inherit-event_caps.patch new file mode 100644 index 00000000000..0e6949327cb --- /dev/null +++ b/queue-5.15/perf-core-inherit-event_caps.patch @@ -0,0 +1,48 @@ +From e3265a4386428d3d157d9565bb520aabff8b4bf0 Mon Sep 17 00:00:00 2001 +From: Namhyung Kim +Date: Mon, 28 Mar 2022 13:01:12 -0700 +Subject: perf/core: Inherit event_caps + +From: Namhyung Kim + +commit e3265a4386428d3d157d9565bb520aabff8b4bf0 upstream. + +It was reported that some perf event setup can make fork failed on +ARM64. It was the case of a group of mixed hw and sw events and it +failed in perf_event_init_task() due to armpmu_event_init(). + +The ARM PMU code checks if all the events in a group belong to the +same PMU except for software events. But it didn't set the event_caps +of inherited events and no longer identify them as software events. +Therefore the test failed in a child process. + +A simple reproducer is: + + $ perf stat -e '{cycles,cs,instructions}' perf bench sched messaging + # Running 'sched/messaging' benchmark: + perf: fork(): Invalid argument + +The perf stat was fine but the perf bench failed in fork(). Let's +inherit the event caps from the parent. + +Signed-off-by: Namhyung Kim +Signed-off-by: Peter Zijlstra (Intel) +Cc: +Link: https://lkml.kernel.org/r/20220328200112.457740-1-namhyung@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + kernel/events/core.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -11596,6 +11596,9 @@ perf_event_alloc(struct perf_event_attr + + event->state = PERF_EVENT_STATE_INACTIVE; + ++ if (parent_event) ++ event->event_caps = parent_event->event_caps; ++ + if (event->attr.sigtrap) + atomic_set(&event->event_limit, 1); + diff --git a/queue-5.15/perf-qcom_l2_pmu-fix-an-incorrect-null-check-on-list-iterator.patch b/queue-5.15/perf-qcom_l2_pmu-fix-an-incorrect-null-check-on-list-iterator.patch new file mode 100644 index 00000000000..c99dded8bda --- /dev/null +++ b/queue-5.15/perf-qcom_l2_pmu-fix-an-incorrect-null-check-on-list-iterator.patch @@ -0,0 +1,53 @@ +From 2012a9e279013933885983cbe0a5fe828052563b Mon Sep 17 00:00:00 2001 +From: Xiaomeng Tong +Date: Sun, 27 Mar 2022 13:57:33 +0800 +Subject: perf: qcom_l2_pmu: fix an incorrect NULL check on list iterator + +From: Xiaomeng Tong + +commit 2012a9e279013933885983cbe0a5fe828052563b upstream. + +The bug is here: + return cluster; + +The list iterator value 'cluster' will *always* be set and non-NULL +by list_for_each_entry(), so it is incorrect to assume that the +iterator value will be NULL if the list is empty or no element +is found. + +To fix the bug, return 'cluster' when found, otherwise return NULL. + +Cc: stable@vger.kernel.org +Fixes: 21bdbb7102ed ("perf: add qcom l2 cache perf events driver") +Signed-off-by: Xiaomeng Tong +Link: https://lore.kernel.org/r/20220327055733.4070-1-xiam0nd.tong@gmail.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + drivers/perf/qcom_l2_pmu.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/perf/qcom_l2_pmu.c ++++ b/drivers/perf/qcom_l2_pmu.c +@@ -736,7 +736,7 @@ static struct cluster_pmu *l2_cache_asso + { + u64 mpidr; + int cpu_cluster_id; +- struct cluster_pmu *cluster = NULL; ++ struct cluster_pmu *cluster; + + /* + * This assumes that the cluster_id is in MPIDR[aff1] for +@@ -758,10 +758,10 @@ static struct cluster_pmu *l2_cache_asso + cluster->cluster_id); + cpumask_set_cpu(cpu, &cluster->cluster_cpus); + *per_cpu_ptr(l2cache_pmu->pmu_cluster, cpu) = cluster; +- break; ++ return cluster; + } + +- return cluster; ++ return NULL; + } + + static int l2cache_pmu_online_cpu(unsigned int cpu, struct hlist_node *node) diff --git a/queue-5.15/perf-x86-intel-don-t-extend-the-pseudo-encoding-to-gp-counters.patch b/queue-5.15/perf-x86-intel-don-t-extend-the-pseudo-encoding-to-gp-counters.patch new file mode 100644 index 00000000000..2ad7a5bdc4c --- /dev/null +++ b/queue-5.15/perf-x86-intel-don-t-extend-the-pseudo-encoding-to-gp-counters.patch @@ -0,0 +1,73 @@ +From 4a263bf331c512849062805ef1b4ac40301a9829 Mon Sep 17 00:00:00 2001 +From: Kan Liang +Date: Mon, 28 Mar 2022 08:49:02 -0700 +Subject: perf/x86/intel: Don't extend the pseudo-encoding to GP counters + +From: Kan Liang + +commit 4a263bf331c512849062805ef1b4ac40301a9829 upstream. + +The INST_RETIRED.PREC_DIST event (0x0100) doesn't count on SPR. +perf stat -e cpu/event=0xc0,umask=0x0/,cpu/event=0x0,umask=0x1/ -C0 + + Performance counter stats for 'CPU(s) 0': + + 607,246 cpu/event=0xc0,umask=0x0/ + 0 cpu/event=0x0,umask=0x1/ + +The encoding for INST_RETIRED.PREC_DIST is pseudo-encoding, which +doesn't work on the generic counters. However, current perf extends its +mask to the generic counters. + +The pseudo event-code for a fixed counter must be 0x00. Check and avoid +extending the mask for the fixed counter event which using the +pseudo-encoding, e.g., ref-cycles and PREC_DIST event. + +With the patch, +perf stat -e cpu/event=0xc0,umask=0x0/,cpu/event=0x0,umask=0x1/ -C0 + + Performance counter stats for 'CPU(s) 0': + + 583,184 cpu/event=0xc0,umask=0x0/ + 583,048 cpu/event=0x0,umask=0x1/ + +Fixes: 2de71ee153ef ("perf/x86/intel: Fix ICL/SPR INST_RETIRED.PREC_DIST encodings") +Signed-off-by: Kan Liang +Signed-off-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/1648482543-14923-1-git-send-email-kan.liang@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/events/intel/core.c | 6 +++++- + arch/x86/include/asm/perf_event.h | 5 +++++ + 2 files changed, 10 insertions(+), 1 deletion(-) + +--- a/arch/x86/events/intel/core.c ++++ b/arch/x86/events/intel/core.c +@@ -5466,7 +5466,11 @@ static void intel_pmu_check_event_constr + /* Disabled fixed counters which are not in CPUID */ + c->idxmsk64 &= intel_ctrl; + +- if (c->idxmsk64 != INTEL_PMC_MSK_FIXED_REF_CYCLES) ++ /* ++ * Don't extend the pseudo-encoding to the ++ * generic counters ++ */ ++ if (!use_fixed_pseudo_encoding(c->code)) + c->idxmsk64 |= (1ULL << num_counters) - 1; + } + c->idxmsk64 &= +--- a/arch/x86/include/asm/perf_event.h ++++ b/arch/x86/include/asm/perf_event.h +@@ -241,6 +241,11 @@ struct x86_pmu_capability { + #define INTEL_PMC_IDX_FIXED_SLOTS (INTEL_PMC_IDX_FIXED + 3) + #define INTEL_PMC_MSK_FIXED_SLOTS (1ULL << INTEL_PMC_IDX_FIXED_SLOTS) + ++static inline bool use_fixed_pseudo_encoding(u64 code) ++{ ++ return !(code & 0xff); ++} ++ + /* + * We model BTS tracing as another fixed-mode PMC. + * diff --git a/queue-5.15/rdma-hfi1-fix-use-after-free-bug-for-mm-struct.patch b/queue-5.15/rdma-hfi1-fix-use-after-free-bug-for-mm-struct.patch new file mode 100644 index 00000000000..dd0c05aec8d --- /dev/null +++ b/queue-5.15/rdma-hfi1-fix-use-after-free-bug-for-mm-struct.patch @@ -0,0 +1,51 @@ +From 2bbac98d0930e8161b1957dc0ec99de39ade1b3c Mon Sep 17 00:00:00 2001 +From: Douglas Miller +Date: Fri, 8 Apr 2022 09:35:23 -0400 +Subject: RDMA/hfi1: Fix use-after-free bug for mm struct + +From: Douglas Miller + +commit 2bbac98d0930e8161b1957dc0ec99de39ade1b3c upstream. + +Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may +represent the last reference held on the task mm. +hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed +before the final use in hfi1_release_user_pages(). A new task may +allocate the mm structure while it is still being used, resulting in +problems. One manifestation is corruption of the mmap_sem counter leading +to a hang in down_write(). Another is corruption of an mm struct that is +in use by another task. + +Fixes: 3d2a9d642512 ("IB/hfi1: Ensure correct mm is used at all times") +Link: https://lore.kernel.org/r/20220408133523.122165.72975.stgit@awfm-01.cornelisnetworks.com +Cc: +Signed-off-by: Douglas Miller +Signed-off-by: Dennis Dalessandro +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/hfi1/mmu_rb.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/infiniband/hw/hfi1/mmu_rb.c ++++ b/drivers/infiniband/hw/hfi1/mmu_rb.c +@@ -80,6 +80,9 @@ void hfi1_mmu_rb_unregister(struct mmu_r + unsigned long flags; + struct list_head del_list; + ++ /* Prevent freeing of mm until we are completely finished. */ ++ mmgrab(handler->mn.mm); ++ + /* Unregister first so we don't get any more notifications. */ + mmu_notifier_unregister(&handler->mn, handler->mn.mm); + +@@ -102,6 +105,9 @@ void hfi1_mmu_rb_unregister(struct mmu_r + + do_remove(handler, &del_list); + ++ /* Now the mm may be freed. */ ++ mmdrop(handler->mn.mm); ++ + kfree(handler); + } + diff --git a/queue-5.15/series b/queue-5.15/series index 2782a13d18d..28b61483c3c 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -225,3 +225,16 @@ perf-x86-intel-update-the-frontend-msr-mask-on-sapphire-rapids.patch btrfs-fix-qgroup-reserve-overflow-the-qgroup-limit.patch btrfs-prevent-subvol-with-swapfile-from-being-deleted.patch spi-core-add-dma_map_dev-for-__spi_unmap_msg.patch +arm64-patch_text-fixup-last-cpu-should-be-master.patch +rdma-hfi1-fix-use-after-free-bug-for-mm-struct.patch +gpio-restrict-usage-of-gpio-chip-irq-members-before-initialization.patch +x86-msi-fix-msi-message-data-shadow-struct.patch +x86-mm-tlb-revert-retpoline-avoidance-approach.patch +perf-x86-intel-don-t-extend-the-pseudo-encoding-to-gp-counters.patch +ata-sata_dwc_460ex-fix-crash-due-to-oob-write.patch +perf-qcom_l2_pmu-fix-an-incorrect-null-check-on-list-iterator.patch +perf-core-inherit-event_caps.patch +irqchip-gic-v3-fix-gicr_ctlr.rwp-polling.patch +fbdev-fix-unregistering-of-framebuffers-without-device.patch +amd-display-set-backlight-only-if-required.patch +sunrpc-prevent-immediate-close-reconnect.patch diff --git a/queue-5.15/sunrpc-prevent-immediate-close-reconnect.patch b/queue-5.15/sunrpc-prevent-immediate-close-reconnect.patch new file mode 100644 index 00000000000..1722d886ef1 --- /dev/null +++ b/queue-5.15/sunrpc-prevent-immediate-close-reconnect.patch @@ -0,0 +1,42 @@ +From 3be232f11a3cc9b0ef0795e39fa11bdb8e422a06 Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Tue, 26 Oct 2021 18:01:07 -0400 +Subject: SUNRPC: Prevent immediate close+reconnect + +From: Trond Myklebust + +commit 3be232f11a3cc9b0ef0795e39fa11bdb8e422a06 upstream. + +If we have already set up the socket and are waiting for it to connect, +then don't immediately close and retry. + +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman +--- + net/sunrpc/xprt.c | 3 ++- + net/sunrpc/xprtsock.c | 2 +- + 2 files changed, 3 insertions(+), 2 deletions(-) + +--- a/net/sunrpc/xprt.c ++++ b/net/sunrpc/xprt.c +@@ -767,7 +767,8 @@ EXPORT_SYMBOL_GPL(xprt_disconnect_done); + */ + static void xprt_schedule_autoclose_locked(struct rpc_xprt *xprt) + { +- set_bit(XPRT_CLOSE_WAIT, &xprt->state); ++ if (test_and_set_bit(XPRT_CLOSE_WAIT, &xprt->state)) ++ return; + if (test_and_set_bit(XPRT_LOCKED, &xprt->state) == 0) + queue_work(xprtiod_workqueue, &xprt->task_cleanup); + else if (xprt->snd_task && !test_bit(XPRT_SND_IS_COOKIE, &xprt->state)) +--- a/net/sunrpc/xprtsock.c ++++ b/net/sunrpc/xprtsock.c +@@ -2365,7 +2365,7 @@ static void xs_connect(struct rpc_xprt * + + WARN_ON_ONCE(!xprt_lock_connect(xprt, task, transport)); + +- if (transport->sock != NULL) { ++ if (transport->sock != NULL && !xprt_connecting(xprt)) { + dprintk("RPC: xs_connect delayed xprt %p for %lu " + "seconds\n", + xprt, xprt->reestablish_timeout / HZ); diff --git a/queue-5.15/x86-mm-tlb-revert-retpoline-avoidance-approach.patch b/queue-5.15/x86-mm-tlb-revert-retpoline-avoidance-approach.patch new file mode 100644 index 00000000000..8aa4c1295e7 --- /dev/null +++ b/queue-5.15/x86-mm-tlb-revert-retpoline-avoidance-approach.patch @@ -0,0 +1,108 @@ +From d39268ad24c0fd0665d0c5cf55a7c1a0ebf94766 Mon Sep 17 00:00:00 2001 +From: Dave Hansen +Date: Fri, 18 Mar 2022 06:52:59 -0700 +Subject: x86/mm/tlb: Revert retpoline avoidance approach + +From: Dave Hansen + +commit d39268ad24c0fd0665d0c5cf55a7c1a0ebf94766 upstream. + +0day reported a regression on a microbenchmark which is intended to +stress the TLB flushing path: + + https://lore.kernel.org/all/20220317090415.GE735@xsang-OptiPlex-9020/ + +It pointed at a commit from Nadav which intended to remove retpoline +overhead in the TLB flushing path by taking the 'cond'-ition in +on_each_cpu_cond_mask(), pre-calculating it, and incorporating it into +'cpumask'. That allowed the code to use a bunch of earlier direct +calls instead of later indirect calls that need a retpoline. + +But, in practice, threads can go idle (and into lazy TLB mode where +they don't need to flush their TLB) between the early and late calls. +It works in this direction and not in the other because TLB-flushing +threads tend to hold mmap_lock for write. Contention on that lock +causes threads to _go_ idle right in this early/late window. + +There was not any performance data in the original commit specific +to the retpoline overhead. I did a few tests on a system with +retpolines: + + https://lore.kernel.org/all/dd8be93c-ded6-b962-50d4-96b1c3afb2b7@intel.com/ + +which showed a possible small win. But, that small win pales in +comparison with the bigger loss induced on non-retpoline systems. + +Revert the patch that removed the retpolines. This was not a +clean revert, but it was self-contained enough not to be too painful. + +Fixes: 6035152d8eeb ("x86/mm/tlb: Open-code on_each_cpu_cond_mask() for tlb_is_not_lazy()") +Reported-by: kernel test robot +Signed-off-by: Dave Hansen +Signed-off-by: Borislav Petkov +Acked-by: Nadav Amit +Cc: +Link: https://lkml.kernel.org/r/164874672286.389.7021457716635788197.tip-bot2@tip-bot2 +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/mm/tlb.c | 37 +++++-------------------------------- + 1 file changed, 5 insertions(+), 32 deletions(-) + +--- a/arch/x86/mm/tlb.c ++++ b/arch/x86/mm/tlb.c +@@ -854,13 +854,11 @@ done: + nr_invalidate); + } + +-static bool tlb_is_not_lazy(int cpu) ++static bool tlb_is_not_lazy(int cpu, void *data) + { + return !per_cpu(cpu_tlbstate_shared.is_lazy, cpu); + } + +-static DEFINE_PER_CPU(cpumask_t, flush_tlb_mask); +- + DEFINE_PER_CPU_SHARED_ALIGNED(struct tlb_state_shared, cpu_tlbstate_shared); + EXPORT_PER_CPU_SYMBOL(cpu_tlbstate_shared); + +@@ -889,36 +887,11 @@ STATIC_NOPV void native_flush_tlb_multi( + * up on the new contents of what used to be page tables, while + * doing a speculative memory access. + */ +- if (info->freed_tables) { ++ if (info->freed_tables) + on_each_cpu_mask(cpumask, flush_tlb_func, (void *)info, true); +- } else { +- /* +- * Although we could have used on_each_cpu_cond_mask(), +- * open-coding it has performance advantages, as it eliminates +- * the need for indirect calls or retpolines. In addition, it +- * allows to use a designated cpumask for evaluating the +- * condition, instead of allocating one. +- * +- * This code works under the assumption that there are no nested +- * TLB flushes, an assumption that is already made in +- * flush_tlb_mm_range(). +- * +- * cond_cpumask is logically a stack-local variable, but it is +- * more efficient to have it off the stack and not to allocate +- * it on demand. Preemption is disabled and this code is +- * non-reentrant. +- */ +- struct cpumask *cond_cpumask = this_cpu_ptr(&flush_tlb_mask); +- int cpu; +- +- cpumask_clear(cond_cpumask); +- +- for_each_cpu(cpu, cpumask) { +- if (tlb_is_not_lazy(cpu)) +- __cpumask_set_cpu(cpu, cond_cpumask); +- } +- on_each_cpu_mask(cond_cpumask, flush_tlb_func, (void *)info, true); +- } ++ else ++ on_each_cpu_cond_mask(tlb_is_not_lazy, flush_tlb_func, ++ (void *)info, 1, cpumask); + } + + void flush_tlb_multi(const struct cpumask *cpumask, diff --git a/queue-5.15/x86-msi-fix-msi-message-data-shadow-struct.patch b/queue-5.15/x86-msi-fix-msi-message-data-shadow-struct.patch new file mode 100644 index 00000000000..246ece69fe1 --- /dev/null +++ b/queue-5.15/x86-msi-fix-msi-message-data-shadow-struct.patch @@ -0,0 +1,53 @@ +From 59b18a1e65b7a2134814106d0860010e10babe18 Mon Sep 17 00:00:00 2001 +From: Reto Buerki +Date: Thu, 7 Apr 2022 13:06:47 +0200 +Subject: x86/msi: Fix msi message data shadow struct + +From: Reto Buerki + +commit 59b18a1e65b7a2134814106d0860010e10babe18 upstream. + +The x86 MSI message data is 32 bits in total and is either in +compatibility or remappable format, see Intel Virtualization Technology +for Directed I/O, section 5.1.2. + +Fixes: 6285aa50736 ("x86/msi: Provide msi message shadow structs") +Co-developed-by: Adrian-Ken Rueegsegger +Signed-off-by: Adrian-Ken Rueegsegger +Signed-off-by: Reto Buerki +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220407110647.67372-1-reet@codelabs.ch +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/msi.h | 19 +++++++++++-------- + 1 file changed, 11 insertions(+), 8 deletions(-) + +--- a/arch/x86/include/asm/msi.h ++++ b/arch/x86/include/asm/msi.h +@@ -12,14 +12,17 @@ int pci_msi_prepare(struct irq_domain *d + /* Structs and defines for the X86 specific MSI message format */ + + typedef struct x86_msi_data { +- u32 vector : 8, +- delivery_mode : 3, +- dest_mode_logical : 1, +- reserved : 2, +- active_low : 1, +- is_level : 1; +- +- u32 dmar_subhandle; ++ union { ++ struct { ++ u32 vector : 8, ++ delivery_mode : 3, ++ dest_mode_logical : 1, ++ reserved : 2, ++ active_low : 1, ++ is_level : 1; ++ }; ++ u32 dmar_subhandle; ++ }; + } __attribute__ ((packed)) arch_msi_msg_data_t; + #define arch_msi_msg_data x86_msi_data +