From: Greg Kroah-Hartman Date: Mon, 29 Aug 2022 08:58:26 +0000 (+0200) Subject: 5.19-stable patches X-Git-Tag: v5.10.140~4 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1664b3b01a29e315ae84e951b8907f2a54eac645;p=thirdparty%2Fkernel%2Fstable-queue.git 5.19-stable patches added patches: arm64-fix-match_list-for-erratum-1286807-on-arm-cortex-a76.patch arm64-fix-rodata-full.patch arm64-signal-flush-fpsimd-register-state-when-disabling-streaming-mode.patch arm64-sme-don-t-flush-sve-register-state-when-allocating-sme-storage.patch arm64-sme-don-t-flush-sve-register-state-when-handling-sme-traps.patch binder_alloc-add-missing-mmap_lock-calls-when-using-the-vma.patch blk-mq-fix-io-hung-due-to-missing-commit_rqs.patch documentation-abi-mention-retbleed-vulnerability-info-file-for-sysfs.patch drm-amdkfd-fix-isa-version-for-the-gc-10.3.7.patch perf-python-fix-build-when-python_config-is-user-supplied.patch perf-stat-clear-evsel-reset_group-for-each-stat-run.patch perf-x86-intel-ds-fix-precise-store-latency-handling.patch perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch riscv-dts-microchip-mpfs-fix-incorrect-pcie-child-node-name.patch riscv-dts-microchip-mpfs-remove-bogus-card-detect-delay.patch riscv-dts-microchip-mpfs-remove-pci-axi-address-translation-property.patch riscv-dts-microchip-mpfs-remove-ti-fifo-depth-property.patch scsi-core-fix-passthrough-retry-counter-handling.patch scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch scsi-ufs-core-enable-link-lost-interrupt.patch x86-nospec-fix-i386-rsb-stuffing.patch --- diff --git a/queue-5.19/arm64-fix-match_list-for-erratum-1286807-on-arm-cortex-a76.patch b/queue-5.19/arm64-fix-match_list-for-erratum-1286807-on-arm-cortex-a76.patch new file mode 100644 index 00000000000..0235e9dce5d --- /dev/null +++ b/queue-5.19/arm64-fix-match_list-for-erratum-1286807-on-arm-cortex-a76.patch @@ -0,0 +1,37 @@ +From 5e1e087457c94ad7fafbe1cf6f774c6999ee29d4 Mon Sep 17 00:00:00 2001 +From: Zenghui Yu +Date: Tue, 9 Aug 2022 12:38:48 +0800 +Subject: arm64: Fix match_list for erratum 1286807 on Arm Cortex-A76 + +From: Zenghui Yu + +commit 5e1e087457c94ad7fafbe1cf6f774c6999ee29d4 upstream. + +Since commit 51f559d66527 ("arm64: Enable repeat tlbi workaround on KRYO4XX +gold CPUs"), we failed to detect erratum 1286807 on Cortex-A76 because its +entry in arm64_repeat_tlbi_list[] was accidently corrupted by this commit. + +Fix this issue by creating a separate entry for Kryo4xx Gold. + +Fixes: 51f559d66527 ("arm64: Enable repeat tlbi workaround on KRYO4XX gold CPUs") +Cc: Shreyas K K +Signed-off-by: Zenghui Yu +Acked-by: Marc Zyngier +Link: https://lore.kernel.org/r/20220809043848.969-1-yuzenghui@huawei.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/cpu_errata.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/arm64/kernel/cpu_errata.c ++++ b/arch/arm64/kernel/cpu_errata.c +@@ -208,6 +208,8 @@ static const struct arm64_cpu_capabiliti + #ifdef CONFIG_ARM64_ERRATUM_1286807 + { + ERRATA_MIDR_RANGE(MIDR_CORTEX_A76, 0, 0, 3, 0), ++ }, ++ { + /* Kryo4xx Gold (rcpe to rfpe) => (r0p0 to r3p0) */ + ERRATA_MIDR_RANGE(MIDR_QCOM_KRYO_4XX_GOLD, 0xc, 0xe, 0xf, 0xe), + }, diff --git a/queue-5.19/arm64-fix-rodata-full.patch b/queue-5.19/arm64-fix-rodata-full.patch new file mode 100644 index 00000000000..a8f0e18fac0 --- /dev/null +++ b/queue-5.19/arm64-fix-rodata-full.patch @@ -0,0 +1,171 @@ +From 2e8cff0a0eee87b27f0cf87ad8310eb41b5886ab Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Wed, 17 Aug 2022 16:40:22 +0100 +Subject: arm64: fix rodata=full + +From: Mark Rutland + +commit 2e8cff0a0eee87b27f0cf87ad8310eb41b5886ab upstream. + +On arm64, "rodata=full" has been suppored (but not documented) since +commit: + + c55191e96caa9d78 ("arm64: mm: apply r/o permissions of VM areas to its linear alias as well") + +As it's necessary to determine the rodata configuration early during +boot, arm64 has an early_param() handler for this, whereas init/main.c +has a __setup() handler which is run later. + +Unfortunately, this split meant that since commit: + + f9a40b0890658330 ("init/main.c: return 1 from handled __setup() functions") + +... passing "rodata=full" would result in a spurious warning from the +__setup() handler (though RO permissions would be configured +appropriately). + +Further, "rodata=full" has been broken since commit: + + 0d6ea3ac94ca77c5 ("lib/kstrtox.c: add "false"/"true" support to kstrtobool()") + +... which caused strtobool() to parse "full" as false (in addition to +many other values not documented for the "rodata=" kernel parameter. + +This patch fixes this breakage by: + +* Moving the core parameter parser to an __early_param(), such that it + is available early. + +* Adding an (optional) arch hook which arm64 can use to parse "full". + +* Updating the documentation to mention that "full" is valid for arm64. + +* Having the core parameter parser handle "on" and "off" explicitly, + such that any undocumented values (e.g. typos such as "ful") are + reported as errors rather than being silently accepted. + +Note that __setup() and early_param() have opposite conventions for +their return values, where __setup() uses 1 to indicate a parameter was +handled and early_param() uses 0 to indicate a parameter was handled. + +Fixes: f9a40b089065 ("init/main.c: return 1 from handled __setup() functions") +Fixes: 0d6ea3ac94ca ("lib/kstrtox.c: add "false"/"true" support to kstrtobool()") +Signed-off-by: Mark Rutland +Cc: Andy Shevchenko +Cc: Ard Biesheuvel +Cc: Catalin Marinas +Cc: Jagdish Gediya +Cc: Matthew Wilcox +Cc: Randy Dunlap +Cc: Will Deacon +Reviewed-by: Ard Biesheuvel +Link: https://lore.kernel.org/r/20220817154022.3974645-1-mark.rutland@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/admin-guide/kernel-parameters.txt | 2 ++ + arch/arm64/include/asm/setup.h | 17 +++++++++++++++++ + arch/arm64/mm/mmu.c | 18 ------------------ + init/main.c | 18 +++++++++++++++--- + 4 files changed, 34 insertions(+), 21 deletions(-) + +--- a/Documentation/admin-guide/kernel-parameters.txt ++++ b/Documentation/admin-guide/kernel-parameters.txt +@@ -5260,6 +5260,8 @@ + rodata= [KNL] + on Mark read-only kernel memory as read-only (default). + off Leave read-only kernel memory writable for debugging. ++ full Mark read-only kernel memory and aliases as read-only ++ [arm64] + + rockchip.usb_uart + Enable the uart passthrough on the designated usb port +--- a/arch/arm64/include/asm/setup.h ++++ b/arch/arm64/include/asm/setup.h +@@ -3,6 +3,8 @@ + #ifndef __ARM64_ASM_SETUP_H + #define __ARM64_ASM_SETUP_H + ++#include ++ + #include + + void *get_early_fdt_ptr(void); +@@ -14,4 +16,19 @@ void early_fdt_map(u64 dt_phys); + extern phys_addr_t __fdt_pointer __initdata; + extern u64 __cacheline_aligned boot_args[4]; + ++static inline bool arch_parse_debug_rodata(char *arg) ++{ ++ extern bool rodata_enabled; ++ extern bool rodata_full; ++ ++ if (arg && !strcmp(arg, "full")) { ++ rodata_enabled = true; ++ rodata_full = true; ++ return true; ++ } ++ ++ return false; ++} ++#define arch_parse_debug_rodata arch_parse_debug_rodata ++ + #endif +--- a/arch/arm64/mm/mmu.c ++++ b/arch/arm64/mm/mmu.c +@@ -625,24 +625,6 @@ static void __init map_kernel_segment(pg + vm_area_add_early(vma); + } + +-static int __init parse_rodata(char *arg) +-{ +- int ret = strtobool(arg, &rodata_enabled); +- if (!ret) { +- rodata_full = false; +- return 0; +- } +- +- /* permit 'full' in addition to boolean options */ +- if (strcmp(arg, "full")) +- return -EINVAL; +- +- rodata_enabled = true; +- rodata_full = true; +- return 0; +-} +-early_param("rodata", parse_rodata); +- + #ifdef CONFIG_UNMAP_KERNEL_AT_EL0 + static int __init map_entry_trampoline(void) + { +--- a/init/main.c ++++ b/init/main.c +@@ -1446,13 +1446,25 @@ static noinline void __init kernel_init_ + + #if defined(CONFIG_STRICT_KERNEL_RWX) || defined(CONFIG_STRICT_MODULE_RWX) + bool rodata_enabled __ro_after_init = true; ++ ++#ifndef arch_parse_debug_rodata ++static inline bool arch_parse_debug_rodata(char *str) { return false; } ++#endif ++ + static int __init set_debug_rodata(char *str) + { +- if (strtobool(str, &rodata_enabled)) ++ if (arch_parse_debug_rodata(str)) ++ return 0; ++ ++ if (str && !strcmp(str, "on")) ++ rodata_enabled = true; ++ else if (str && !strcmp(str, "off")) ++ rodata_enabled = false; ++ else + pr_warn("Invalid option string for rodata: '%s'\n", str); +- return 1; ++ return 0; + } +-__setup("rodata=", set_debug_rodata); ++early_param("rodata", set_debug_rodata); + #endif + + #ifdef CONFIG_STRICT_KERNEL_RWX diff --git a/queue-5.19/arm64-signal-flush-fpsimd-register-state-when-disabling-streaming-mode.patch b/queue-5.19/arm64-signal-flush-fpsimd-register-state-when-disabling-streaming-mode.patch new file mode 100644 index 00000000000..92e97fb663a --- /dev/null +++ b/queue-5.19/arm64-signal-flush-fpsimd-register-state-when-disabling-streaming-mode.patch @@ -0,0 +1,45 @@ +From ea64baacbc36a0d552aec0d87107182f40211131 Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Wed, 17 Aug 2022 19:23:22 +0100 +Subject: arm64/signal: Flush FPSIMD register state when disabling streaming mode + +From: Mark Brown + +commit ea64baacbc36a0d552aec0d87107182f40211131 upstream. + +When handling a signal delivered to a context with streaming mode enabled +we will disable streaming mode for the signal handler, when doing so we +should also flush the saved FPSIMD register state like exiting streaming +mode in the hardware would do so that if that state is reloaded we get the +same behaviour. Without this we will reload whatever the last FPSIMD state +that was saved for the task was. + +Fixes: 40a8e87bb328 ("arm64/sme: Disable ZA and streaming mode when handling signals") +Signed-off-by: Mark Brown +Reviewed-by: Catalin Marinas +Link: https://lore.kernel.org/r/20220817182324.638214-3-broonie@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/signal.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/arch/arm64/kernel/signal.c ++++ b/arch/arm64/kernel/signal.c +@@ -922,6 +922,16 @@ static void setup_return(struct pt_regs + + /* Signal handlers are invoked with ZA and streaming mode disabled */ + if (system_supports_sme()) { ++ /* ++ * If we were in streaming mode the saved register ++ * state was SVE but we will exit SM and use the ++ * FPSIMD register state - flush the saved FPSIMD ++ * register state in case it gets loaded. ++ */ ++ if (current->thread.svcr & SVCR_SM_MASK) ++ memset(¤t->thread.uw.fpsimd_state, 0, ++ sizeof(current->thread.uw.fpsimd_state)); ++ + current->thread.svcr &= ~(SVCR_ZA_MASK | + SVCR_SM_MASK); + sme_smstop(); diff --git a/queue-5.19/arm64-sme-don-t-flush-sve-register-state-when-allocating-sme-storage.patch b/queue-5.19/arm64-sme-don-t-flush-sve-register-state-when-allocating-sme-storage.patch new file mode 100644 index 00000000000..9b2bbef5f33 --- /dev/null +++ b/queue-5.19/arm64-sme-don-t-flush-sve-register-state-when-allocating-sme-storage.patch @@ -0,0 +1,130 @@ +From 826a4fdd2ada9e5923c58bdd168f31a42e958ffc Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Wed, 17 Aug 2022 19:23:23 +0100 +Subject: arm64/sme: Don't flush SVE register state when allocating SME storage + +From: Mark Brown + +commit 826a4fdd2ada9e5923c58bdd168f31a42e958ffc upstream. + +Currently when taking a SME access trap we allocate storage for the SVE +register state in order to be able to handle storage of streaming mode SVE. +Due to the original usage in a purely SVE context the SVE register state +allocation this also flushes the register state for SVE if storage was +already allocated but in the SME context this is not desirable. For a SME +access trap to be taken the task must not be in streaming mode so either +there already is SVE register state present for regular SVE mode which would +be corrupted or the task does not have TIF_SVE and the flush is redundant. + +Fix this by adding a flag to sve_alloc() indicating if we are in a SVE +context and need to flush the state. Freshly allocated storage is always +zeroed either way. + +Fixes: 8bd7f91c03d8 ("arm64/sme: Implement traps and syscall handling for SME") +Signed-off-by: Mark Brown +Reviewed-by: Catalin Marinas +Link: https://lore.kernel.org/r/20220817182324.638214-4-broonie@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/include/asm/fpsimd.h | 4 ++-- + arch/arm64/kernel/fpsimd.c | 10 ++++++---- + arch/arm64/kernel/ptrace.c | 6 +++--- + arch/arm64/kernel/signal.c | 2 +- + 4 files changed, 12 insertions(+), 10 deletions(-) + +--- a/arch/arm64/include/asm/fpsimd.h ++++ b/arch/arm64/include/asm/fpsimd.h +@@ -153,7 +153,7 @@ struct vl_info { + + #ifdef CONFIG_ARM64_SVE + +-extern void sve_alloc(struct task_struct *task); ++extern void sve_alloc(struct task_struct *task, bool flush); + extern void fpsimd_release_task(struct task_struct *task); + extern void fpsimd_sync_to_sve(struct task_struct *task); + extern void fpsimd_force_sync_to_sve(struct task_struct *task); +@@ -256,7 +256,7 @@ size_t sve_state_size(struct task_struct + + #else /* ! CONFIG_ARM64_SVE */ + +-static inline void sve_alloc(struct task_struct *task) { } ++static inline void sve_alloc(struct task_struct *task, bool flush) { } + static inline void fpsimd_release_task(struct task_struct *task) { } + static inline void sve_sync_to_fpsimd(struct task_struct *task) { } + static inline void sve_sync_from_fpsimd_zeropad(struct task_struct *task) { } +--- a/arch/arm64/kernel/fpsimd.c ++++ b/arch/arm64/kernel/fpsimd.c +@@ -716,10 +716,12 @@ size_t sve_state_size(struct task_struct + * do_sve_acc() case, there is no ABI requirement to hide stale data + * written previously be task. + */ +-void sve_alloc(struct task_struct *task) ++void sve_alloc(struct task_struct *task, bool flush) + { + if (task->thread.sve_state) { +- memset(task->thread.sve_state, 0, sve_state_size(task)); ++ if (flush) ++ memset(task->thread.sve_state, 0, ++ sve_state_size(task)); + return; + } + +@@ -1389,7 +1391,7 @@ void do_sve_acc(unsigned long esr, struc + return; + } + +- sve_alloc(current); ++ sve_alloc(current, true); + if (!current->thread.sve_state) { + force_sig(SIGKILL); + return; +@@ -1440,7 +1442,7 @@ void do_sme_acc(unsigned long esr, struc + return; + } + +- sve_alloc(current); ++ sve_alloc(current, false); + sme_alloc(current); + if (!current->thread.sve_state || !current->thread.za_state) { + force_sig(SIGKILL); +--- a/arch/arm64/kernel/ptrace.c ++++ b/arch/arm64/kernel/ptrace.c +@@ -882,7 +882,7 @@ static int sve_set_common(struct task_st + * state and ensure there's storage. + */ + if (target->thread.svcr != old_svcr) +- sve_alloc(target); ++ sve_alloc(target, true); + } + + /* Registers: FPSIMD-only case */ +@@ -912,7 +912,7 @@ static int sve_set_common(struct task_st + goto out; + } + +- sve_alloc(target); ++ sve_alloc(target, true); + if (!target->thread.sve_state) { + ret = -ENOMEM; + clear_tsk_thread_flag(target, TIF_SVE); +@@ -1082,7 +1082,7 @@ static int za_set(struct task_struct *ta + + /* Ensure there is some SVE storage for streaming mode */ + if (!target->thread.sve_state) { +- sve_alloc(target); ++ sve_alloc(target, false); + if (!target->thread.sve_state) { + clear_thread_flag(TIF_SME); + ret = -ENOMEM; +--- a/arch/arm64/kernel/signal.c ++++ b/arch/arm64/kernel/signal.c +@@ -307,7 +307,7 @@ static int restore_sve_fpsimd_context(st + fpsimd_flush_task_state(current); + /* From now, fpsimd_thread_switch() won't touch thread.sve_state */ + +- sve_alloc(current); ++ sve_alloc(current, true); + if (!current->thread.sve_state) { + clear_thread_flag(TIF_SVE); + return -ENOMEM; diff --git a/queue-5.19/arm64-sme-don-t-flush-sve-register-state-when-handling-sme-traps.patch b/queue-5.19/arm64-sme-don-t-flush-sve-register-state-when-handling-sme-traps.patch new file mode 100644 index 00000000000..bd4edb1fa79 --- /dev/null +++ b/queue-5.19/arm64-sme-don-t-flush-sve-register-state-when-handling-sme-traps.patch @@ -0,0 +1,47 @@ +From 714f3cbd70a4db9f9b7fe5b8a032896ed33fb824 Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Wed, 17 Aug 2022 19:23:24 +0100 +Subject: arm64/sme: Don't flush SVE register state when handling SME traps + +From: Mark Brown + +commit 714f3cbd70a4db9f9b7fe5b8a032896ed33fb824 upstream. + +Currently as part of handling a SME access trap we flush the SVE register +state. This is not needed and would corrupt register state if the task has +access to the SVE registers already. For non-streaming mode accesses the +required flushing will be done in the SVE access trap. For streaming +mode SVE register accesses the architecture guarantees that the register +state will be flushed when streaming mode is entered or exited so there is +no need for us to do so. Simply remove the register initialisation. + +Fixes: 8bd7f91c03d8 ("arm64/sme: Implement traps and syscall handling for SME") +Signed-off-by: Mark Brown +Reviewed-by: Catalin Marinas +Link: https://lore.kernel.org/r/20220817182324.638214-5-broonie@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/fpsimd.c | 11 ----------- + 1 file changed, 11 deletions(-) + +--- a/arch/arm64/kernel/fpsimd.c ++++ b/arch/arm64/kernel/fpsimd.c +@@ -1463,17 +1463,6 @@ void do_sme_acc(unsigned long esr, struc + fpsimd_bind_task_to_cpu(); + } + +- /* +- * If SVE was not already active initialise the SVE registers, +- * any non-shared state between the streaming and regular SVE +- * registers is architecturally guaranteed to be zeroed when +- * we enter streaming mode. We do not need to initialize ZA +- * since ZA must be disabled at this point and enabling ZA is +- * architecturally defined to zero ZA. +- */ +- if (system_supports_sve() && !test_thread_flag(TIF_SVE)) +- sve_init_regs(); +- + put_cpu_fpsimd_context(); + } + diff --git a/queue-5.19/binder_alloc-add-missing-mmap_lock-calls-when-using-the-vma.patch b/queue-5.19/binder_alloc-add-missing-mmap_lock-calls-when-using-the-vma.patch new file mode 100644 index 00000000000..edc08a8c97a --- /dev/null +++ b/queue-5.19/binder_alloc-add-missing-mmap_lock-calls-when-using-the-vma.patch @@ -0,0 +1,96 @@ +From 44e602b4e52f70f04620bbbf4fe46ecb40170bde Mon Sep 17 00:00:00 2001 +From: Liam Howlett +Date: Wed, 10 Aug 2022 16:02:25 +0000 +Subject: binder_alloc: add missing mmap_lock calls when using the VMA +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Liam Howlett + +commit 44e602b4e52f70f04620bbbf4fe46ecb40170bde upstream. + +Take the mmap_read_lock() when using the VMA in binder_alloc_print_pages() +and when checking for a VMA in binder_alloc_new_buf_locked(). + +It is worth noting binder_alloc_new_buf_locked() drops the VMA read lock +after it verifies a VMA exists, but may be taken again deeper in the call +stack, if necessary. + +Link: https://lkml.kernel.org/r/20220810160209.1630707-1-Liam.Howlett@oracle.com +Fixes: a43cfc87caaf (android: binder: stop saving a pointer to the VMA) +Signed-off-by: Liam R. Howlett +Reported-by: Ondrej Mosnacek +Reported-by: +Acked-by: Carlos Llamas +Tested-by: Ondrej Mosnacek +Cc: Minchan Kim +Cc: Christian Brauner (Microsoft) +Cc: Greg Kroah-Hartman +Cc: Hridya Valsaraju +Cc: Joel Fernandes +Cc: Martijn Coenen +Cc: Suren Baghdasaryan +Cc: Todd Kjos +Cc: Matthew Wilcox (Oracle) +Cc: "Arve HjønnevÃ¥g" +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + drivers/android/binder_alloc.c | 31 +++++++++++++++++++++---------- + 1 file changed, 21 insertions(+), 10 deletions(-) + +--- a/drivers/android/binder_alloc.c ++++ b/drivers/android/binder_alloc.c +@@ -395,12 +395,15 @@ static struct binder_buffer *binder_allo + size_t size, data_offsets_size; + int ret; + ++ mmap_read_lock(alloc->vma_vm_mm); + if (!binder_alloc_get_vma(alloc)) { ++ mmap_read_unlock(alloc->vma_vm_mm); + binder_alloc_debug(BINDER_DEBUG_USER_ERROR, + "%d: binder_alloc_buf, no vma\n", + alloc->pid); + return ERR_PTR(-ESRCH); + } ++ mmap_read_unlock(alloc->vma_vm_mm); + + data_offsets_size = ALIGN(data_size, sizeof(void *)) + + ALIGN(offsets_size, sizeof(void *)); +@@ -922,17 +925,25 @@ void binder_alloc_print_pages(struct seq + * Make sure the binder_alloc is fully initialized, otherwise we might + * read inconsistent state. + */ +- if (binder_alloc_get_vma(alloc) != NULL) { +- for (i = 0; i < alloc->buffer_size / PAGE_SIZE; i++) { +- page = &alloc->pages[i]; +- if (!page->page_ptr) +- free++; +- else if (list_empty(&page->lru)) +- active++; +- else +- lru++; +- } ++ ++ mmap_read_lock(alloc->vma_vm_mm); ++ if (binder_alloc_get_vma(alloc) == NULL) { ++ mmap_read_unlock(alloc->vma_vm_mm); ++ goto uninitialized; ++ } ++ ++ mmap_read_unlock(alloc->vma_vm_mm); ++ for (i = 0; i < alloc->buffer_size / PAGE_SIZE; i++) { ++ page = &alloc->pages[i]; ++ if (!page->page_ptr) ++ free++; ++ else if (list_empty(&page->lru)) ++ active++; ++ else ++ lru++; + } ++ ++uninitialized: + mutex_unlock(&alloc->mutex); + seq_printf(m, " pages: %d:%d:%d\n", active, lru, free); + seq_printf(m, " pages high watermark: %zu\n", alloc->pages_high); diff --git a/queue-5.19/blk-mq-fix-io-hung-due-to-missing-commit_rqs.patch b/queue-5.19/blk-mq-fix-io-hung-due-to-missing-commit_rqs.patch new file mode 100644 index 00000000000..6a0f1cadc25 --- /dev/null +++ b/queue-5.19/blk-mq-fix-io-hung-due-to-missing-commit_rqs.patch @@ -0,0 +1,94 @@ +From 65fac0d54f374625b43a9d6ad1f2c212bd41f518 Mon Sep 17 00:00:00 2001 +From: Yu Kuai +Date: Tue, 26 Jul 2022 20:22:24 +0800 +Subject: blk-mq: fix io hung due to missing commit_rqs + +From: Yu Kuai + +commit 65fac0d54f374625b43a9d6ad1f2c212bd41f518 upstream. + +Currently, in virtio_scsi, if 'bd->last' is not set to true while +dispatching request, such io will stay in driver's queue, and driver +will wait for block layer to dispatch more rqs. However, if block +layer failed to dispatch more rq, it should trigger commit_rqs to +inform driver. + +There is a problem in blk_mq_try_issue_list_directly() that commit_rqs +won't be called: + +// assume that queue_depth is set to 1, list contains two rq +blk_mq_try_issue_list_directly + blk_mq_request_issue_directly + // dispatch first rq + // last is false + __blk_mq_try_issue_directly + blk_mq_get_dispatch_budget + // succeed to get first budget + __blk_mq_issue_directly + scsi_queue_rq + cmd->flags |= SCMD_LAST + virtscsi_queuecommand + kick = (sc->flags & SCMD_LAST) != 0 + // kick is false, first rq won't issue to disk + queued++ + + blk_mq_request_issue_directly + // dispatch second rq + __blk_mq_try_issue_directly + blk_mq_get_dispatch_budget + // failed to get second budget + ret == BLK_STS_RESOURCE + blk_mq_request_bypass_insert + // errors is still 0 + + if (!list_empty(list) || errors && ...) + // won't pass, commit_rqs won't be called + +In this situation, first rq relied on second rq to dispatch, while +second rq relied on first rq to complete, thus they will both hung. + +Fix the problem by also treat 'BLK_STS_*RESOURCE' as 'errors' since +it means that request is not queued successfully. + +Same problem exists in blk_mq_dispatch_rq_list(), 'BLK_STS_*RESOURCE' +can't be treated as 'errors' here, fix the problem by calling +commit_rqs if queue_rq return 'BLK_STS_*RESOURCE'. + +Fixes: d666ba98f849 ("blk-mq: add mq_ops->commit_rqs()") +Signed-off-by: Yu Kuai +Reviewed-by: Ming Lei +Link: https://lore.kernel.org/r/20220726122224.1790882-1-yukuai1@huaweicloud.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/blk-mq.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/block/blk-mq.c ++++ b/block/blk-mq.c +@@ -1925,7 +1925,8 @@ out: + /* If we didn't flush the entire list, we could have told the driver + * there was more coming, but that turned out to be a lie. + */ +- if ((!list_empty(list) || errors) && q->mq_ops->commit_rqs && queued) ++ if ((!list_empty(list) || errors || needs_resource || ++ ret == BLK_STS_DEV_RESOURCE) && q->mq_ops->commit_rqs && queued) + q->mq_ops->commit_rqs(hctx); + /* + * Any items that need requeuing? Stuff them into hctx->dispatch, +@@ -2678,6 +2679,7 @@ void blk_mq_try_issue_list_directly(stru + list_del_init(&rq->queuelist); + ret = blk_mq_request_issue_directly(rq, list_empty(list)); + if (ret != BLK_STS_OK) { ++ errors++; + if (ret == BLK_STS_RESOURCE || + ret == BLK_STS_DEV_RESOURCE) { + blk_mq_request_bypass_insert(rq, false, +@@ -2685,7 +2687,6 @@ void blk_mq_try_issue_list_directly(stru + break; + } + blk_mq_end_request(rq, ret); +- errors++; + } else + queued++; + } diff --git a/queue-5.19/documentation-abi-mention-retbleed-vulnerability-info-file-for-sysfs.patch b/queue-5.19/documentation-abi-mention-retbleed-vulnerability-info-file-for-sysfs.patch new file mode 100644 index 00000000000..28fadff96f2 --- /dev/null +++ b/queue-5.19/documentation-abi-mention-retbleed-vulnerability-info-file-for-sysfs.patch @@ -0,0 +1,35 @@ +From 00da0cb385d05a89226e150a102eb49d8abb0359 Mon Sep 17 00:00:00 2001 +From: Salvatore Bonaccorso +Date: Mon, 1 Aug 2022 11:15:30 +0200 +Subject: Documentation/ABI: Mention retbleed vulnerability info file for sysfs + +From: Salvatore Bonaccorso + +commit 00da0cb385d05a89226e150a102eb49d8abb0359 upstream. + +While reporting for the AMD retbleed vulnerability was added in + + 6b80b59b3555 ("x86/bugs: Report AMD retbleed vulnerability") + +the new sysfs file was not mentioned so far in the ABI documentation for +sysfs-devices-system-cpu. Fix that. + +Fixes: 6b80b59b3555 ("x86/bugs: Report AMD retbleed vulnerability") +Signed-off-by: Salvatore Bonaccorso +Signed-off-by: Borislav Petkov +Link: https://lore.kernel.org/r/20220801091529.325327-1-carnil@debian.org +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + + 1 file changed, 1 insertion(+) + +--- a/Documentation/ABI/testing/sysfs-devices-system-cpu ++++ b/Documentation/ABI/testing/sysfs-devices-system-cpu +@@ -527,6 +527,7 @@ What: /sys/devices/system/cpu/vulnerabi + /sys/devices/system/cpu/vulnerabilities/tsx_async_abort + /sys/devices/system/cpu/vulnerabilities/itlb_multihit + /sys/devices/system/cpu/vulnerabilities/mmio_stale_data ++ /sys/devices/system/cpu/vulnerabilities/retbleed + Date: January 2018 + Contact: Linux kernel mailing list + Description: Information about CPU vulnerabilities diff --git a/queue-5.19/drm-amdkfd-fix-isa-version-for-the-gc-10.3.7.patch b/queue-5.19/drm-amdkfd-fix-isa-version-for-the-gc-10.3.7.patch new file mode 100644 index 00000000000..d482a8c4433 --- /dev/null +++ b/queue-5.19/drm-amdkfd-fix-isa-version-for-the-gc-10.3.7.patch @@ -0,0 +1,36 @@ +From ee8086dbc1585d9f4020a19447388246a5cff5c8 Mon Sep 17 00:00:00 2001 +From: Prike Liang +Date: Wed, 24 Aug 2022 11:16:51 +0800 +Subject: drm/amdkfd: Fix isa version for the GC 10.3.7 + +From: Prike Liang + +commit ee8086dbc1585d9f4020a19447388246a5cff5c8 upstream. + +Correct the isa version for handling KFD test. + +Fixes: 7c4f4f197e0c ("drm/amdkfd: Add GC 10.3.6 and 10.3.7 KFD definitions") +Signed-off-by: Prike Liang +Reviewed-by: Aaron Liu +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdkfd/kfd_device.c | 6 +----- + 1 file changed, 1 insertion(+), 5 deletions(-) + +--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c +@@ -377,12 +377,8 @@ struct kfd_dev *kgd2kfd_probe(struct amd + f2g = &gfx_v10_3_kfd2kgd; + break; + case IP_VERSION(10, 3, 6): +- gfx_target_version = 100306; +- if (!vf) +- f2g = &gfx_v10_3_kfd2kgd; +- break; + case IP_VERSION(10, 3, 7): +- gfx_target_version = 100307; ++ gfx_target_version = 100306; + if (!vf) + f2g = &gfx_v10_3_kfd2kgd; + break; diff --git a/queue-5.19/perf-python-fix-build-when-python_config-is-user-supplied.patch b/queue-5.19/perf-python-fix-build-when-python_config-is-user-supplied.patch new file mode 100644 index 00000000000..30d4f3ece7f --- /dev/null +++ b/queue-5.19/perf-python-fix-build-when-python_config-is-user-supplied.patch @@ -0,0 +1,53 @@ +From bc9e7fe313d5e56d4d5f34bcc04d1165f94f86fb Mon Sep 17 00:00:00 2001 +From: James Clark +Date: Thu, 28 Jul 2022 10:39:46 +0100 +Subject: perf python: Fix build when PYTHON_CONFIG is user supplied + +From: James Clark + +commit bc9e7fe313d5e56d4d5f34bcc04d1165f94f86fb upstream. + +The previous change to Python autodetection had a small mistake where +the auto value was used to determine the Python binary, rather than the +user supplied value. The Python binary is only used for one part of the +build process, rather than the final linking, so it was producing +correct builds in most scenarios, especially when the auto detected +value matched what the user wanted, or the system only had a valid set +of Pythons. + +Change it so that the Python binary path is derived from either the +PYTHON_CONFIG value or PYTHON value, depending on what is specified by +the user. This was the original intention. + +This error was spotted in a build failure an odd cross compilation +environment after commit 4c41cb46a732fe82 ("perf python: Prefer +python3") was merged. + +Fixes: 630af16eee495f58 ("perf tools: Use Python devtools for version autodetection rather than runtime") +Signed-off-by: James Clark +Acked-by: Ian Rogers +Cc: Alexander Shishkin +Cc: Ingo Molnar +Cc: James Clark +Cc: Jiri Olsa +Cc: Mark Rutland +Cc: Namhyung Kim +Cc: Peter Zijlstra +Link: https://lore.kernel.org/r/20220728093946.1337642-1-james.clark@arm.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman +--- + tools/perf/Makefile.config | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/perf/Makefile.config ++++ b/tools/perf/Makefile.config +@@ -265,7 +265,7 @@ endif + # defined. get-executable-or-default fails with an error if the first argument is supplied but + # doesn't exist. + override PYTHON_CONFIG := $(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON_AUTO)) +-override PYTHON := $(call get-executable-or-default,PYTHON,$(subst -config,,$(PYTHON_AUTO))) ++override PYTHON := $(call get-executable-or-default,PYTHON,$(subst -config,,$(PYTHON_CONFIG))) + + grep-libs = $(filter -l%,$(1)) + strip-libs = $(filter-out -l%,$(1)) diff --git a/queue-5.19/perf-stat-clear-evsel-reset_group-for-each-stat-run.patch b/queue-5.19/perf-stat-clear-evsel-reset_group-for-each-stat-run.patch new file mode 100644 index 00000000000..a0fd8a62372 --- /dev/null +++ b/queue-5.19/perf-stat-clear-evsel-reset_group-for-each-stat-run.patch @@ -0,0 +1,50 @@ +From bf515f024e4c0ca46a1b08c4f31860c01781d8a5 Mon Sep 17 00:00:00 2001 +From: Ian Rogers +Date: Mon, 22 Aug 2022 14:33:51 -0700 +Subject: perf stat: Clear evsel->reset_group for each stat run + +From: Ian Rogers + +commit bf515f024e4c0ca46a1b08c4f31860c01781d8a5 upstream. + +If a weak group is broken then the reset_group flag remains set for +the next run. Having reset_group set means the counter isn't created +and ultimately a segfault. + +A simple reproduction of this is: + + # perf stat -r2 -e '{cycles,cycles,cycles,cycles,cycles,cycles,cycles,cycles,cycles,cycles}:W + +which will be added as a test in the next patch. + +Fixes: 4804e0111662d7d8 ("perf stat: Use affinity for opening events") +Reviewed-by: Andi Kleen +Signed-off-by: Ian Rogers +Tested-by: Arnaldo Carvalho de Melo +Tested-by: Xing Zhengjun +Cc: Alexander Shishkin +Cc: Andi Kleen +Cc: Ingo Molnar +Cc: Jiri Olsa +Cc: Kan Liang +Cc: Mark Rutland +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Stephane Eranian +Link: https://lore.kernel.org/r/20220822213352.75721-1-irogers@google.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman +--- + tools/perf/builtin-stat.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/tools/perf/builtin-stat.c ++++ b/tools/perf/builtin-stat.c +@@ -826,6 +826,7 @@ static int __run_perf_stat(int argc, con + } + + evlist__for_each_entry(evsel_list, counter) { ++ counter->reset_group = false; + if (bpf_counter__load(counter, &target)) + return -1; + if (!evsel__is_bpf(counter)) diff --git a/queue-5.19/perf-x86-intel-ds-fix-precise-store-latency-handling.patch b/queue-5.19/perf-x86-intel-ds-fix-precise-store-latency-handling.patch new file mode 100644 index 00000000000..6b9fa63edcb --- /dev/null +++ b/queue-5.19/perf-x86-intel-ds-fix-precise-store-latency-handling.patch @@ -0,0 +1,52 @@ +From d4bdb0bebc5ba3299d74f123c782d99cd4e25c49 Mon Sep 17 00:00:00 2001 +From: Stephane Eranian +Date: Wed, 17 Aug 2022 22:46:13 -0700 +Subject: perf/x86/intel/ds: Fix precise store latency handling + +From: Stephane Eranian + +commit d4bdb0bebc5ba3299d74f123c782d99cd4e25c49 upstream. + +With the existing code in store_latency_data(), the memory operation (mem_op) +returned to the user is always OP_LOAD where in fact, it should be OP_STORE. +This comes from the fact that the function is simply grabbing the information +from a data source map which covers only load accesses. Intel 12th gen CPU +offers precise store sampling that captures both the data source and latency. +Therefore it can use the data source mapping table but must override the +memory operation to reflect stores instead of loads. + +Fixes: 61b985e3e775 ("perf/x86/intel: Add perf core PMU support for Sapphire Rapids") +Signed-off-by: Stephane Eranian +Signed-off-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/20220818054613.1548130-1-eranian@google.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/events/intel/ds.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/arch/x86/events/intel/ds.c ++++ b/arch/x86/events/intel/ds.c +@@ -291,6 +291,7 @@ static u64 load_latency_data(struct perf + static u64 store_latency_data(struct perf_event *event, u64 status) + { + union intel_x86_pebs_dse dse; ++ union perf_mem_data_src src; + u64 val; + + dse.val = status; +@@ -304,7 +305,14 @@ static u64 store_latency_data(struct per + + val |= P(BLK, NA); + +- return val; ++ /* ++ * the pebs_data_source table is only for loads ++ * so override the mem_op to say STORE instead ++ */ ++ src.val = val; ++ src.mem_op = P(OP,STORE); ++ ++ return src.val; + } + + struct pebs_record_core { diff --git a/queue-5.19/perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch b/queue-5.19/perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch new file mode 100644 index 00000000000..8ec2bdbe191 --- /dev/null +++ b/queue-5.19/perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch @@ -0,0 +1,85 @@ +From 11745ecfe8fea4b4a4c322967a7605d2ecbd5080 Mon Sep 17 00:00:00 2001 +From: Stephane Eranian +Date: Wed, 3 Aug 2022 09:00:31 -0700 +Subject: perf/x86/intel/uncore: Fix broken read_counter() for SNB IMC PMU + +From: Stephane Eranian + +commit 11745ecfe8fea4b4a4c322967a7605d2ecbd5080 upstream. + +Existing code was generating bogus counts for the SNB IMC bandwidth counters: + +$ perf stat -a -I 1000 -e uncore_imc/data_reads/,uncore_imc/data_writes/ + 1.000327813 1,024.03 MiB uncore_imc/data_reads/ + 1.000327813 20.73 MiB uncore_imc/data_writes/ + 2.000580153 261,120.00 MiB uncore_imc/data_reads/ + 2.000580153 23.28 MiB uncore_imc/data_writes/ + +The problem was introduced by commit: + 07ce734dd8ad ("perf/x86/intel/uncore: Clean up client IMC") + +Where the read_counter callback was replace to point to the generic +uncore_mmio_read_counter() function. + +The SNB IMC counters are freerunnig 32-bit counters laid out contiguously in +MMIO. But uncore_mmio_read_counter() is using a readq() call to read from +MMIO therefore reading 64-bit from MMIO. Although this is okay for the +uncore_perf_event_update() function because it is shifting the value based +on the actual counter width to compute a delta, it is not okay for the +uncore_pmu_event_start() which is simply reading the counter and therefore +priming the event->prev_count with a bogus value which is responsible for +causing bogus deltas in the perf stat command above. + +The fix is to reintroduce the custom callback for read_counter for the SNB +IMC PMU and use readl() instead of readq(). With the change the output of +perf stat is back to normal: +$ perf stat -a -I 1000 -e uncore_imc/data_reads/,uncore_imc/data_writes/ + 1.000120987 296.94 MiB uncore_imc/data_reads/ + 1.000120987 138.42 MiB uncore_imc/data_writes/ + 2.000403144 175.91 MiB uncore_imc/data_reads/ + 2.000403144 68.50 MiB uncore_imc/data_writes/ + +Fixes: 07ce734dd8ad ("perf/x86/intel/uncore: Clean up client IMC") +Signed-off-by: Stephane Eranian +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Kan Liang +Link: https://lore.kernel.org/r/20220803160031.1379788-1-eranian@google.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/events/intel/uncore_snb.c | 18 +++++++++++++++++- + 1 file changed, 17 insertions(+), 1 deletion(-) + +--- a/arch/x86/events/intel/uncore_snb.c ++++ b/arch/x86/events/intel/uncore_snb.c +@@ -841,6 +841,22 @@ int snb_pci2phy_map_init(int devid) + return 0; + } + ++static u64 snb_uncore_imc_read_counter(struct intel_uncore_box *box, struct perf_event *event) ++{ ++ struct hw_perf_event *hwc = &event->hw; ++ ++ /* ++ * SNB IMC counters are 32-bit and are laid out back to back ++ * in MMIO space. Therefore we must use a 32-bit accessor function ++ * using readq() from uncore_mmio_read_counter() causes problems ++ * because it is reading 64-bit at a time. This is okay for the ++ * uncore_perf_event_update() function because it drops the upper ++ * 32-bits but not okay for plain uncore_read_counter() as invoked ++ * in uncore_pmu_event_start(). ++ */ ++ return (u64)readl(box->io_addr + hwc->event_base); ++} ++ + static struct pmu snb_uncore_imc_pmu = { + .task_ctx_nr = perf_invalid_context, + .event_init = snb_uncore_imc_event_init, +@@ -860,7 +876,7 @@ static struct intel_uncore_ops snb_uncor + .disable_event = snb_uncore_imc_disable_event, + .enable_event = snb_uncore_imc_enable_event, + .hw_config = snb_uncore_imc_hw_config, +- .read_counter = uncore_mmio_read_counter, ++ .read_counter = snb_uncore_imc_read_counter, + }; + + static struct intel_uncore_type snb_uncore_imc = { diff --git a/queue-5.19/riscv-dts-microchip-mpfs-fix-incorrect-pcie-child-node-name.patch b/queue-5.19/riscv-dts-microchip-mpfs-fix-incorrect-pcie-child-node-name.patch new file mode 100644 index 00000000000..7a68ed04cad --- /dev/null +++ b/queue-5.19/riscv-dts-microchip-mpfs-fix-incorrect-pcie-child-node-name.patch @@ -0,0 +1,33 @@ +From 3f67e69976035352db110443916bcce32c7f64ac Mon Sep 17 00:00:00 2001 +From: Conor Dooley +Date: Sat, 20 Aug 2022 00:14:13 +0100 +Subject: riscv: dts: microchip: mpfs: fix incorrect pcie child node name + +From: Conor Dooley + +commit 3f67e69976035352db110443916bcce32c7f64ac upstream. + +Recent versions of dt-schema complain about the PCIe controller's child +node name: +arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dtb: pcie@2000000000: Unevaluated properties are not allowed ('clock-names', 'clocks', 'legacy-interrupt-controller', 'microchip,axi-m-atr0' were unexpected) + From schema: Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml +Make the dts match the correct property name in the dts. + +Fixes: 528a5b1f2556 ("riscv: dts: microchip: add new peripherals to icicle kit device tree") +Signed-off-by: Conor Dooley +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/boot/dts/microchip/mpfs.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/riscv/boot/dts/microchip/mpfs.dtsi ++++ b/arch/riscv/boot/dts/microchip/mpfs.dtsi +@@ -448,7 +448,7 @@ + msi-controller; + microchip,axi-m-atr0 = <0x10 0x0>; + status = "disabled"; +- pcie_intc: legacy-interrupt-controller { ++ pcie_intc: interrupt-controller { + #address-cells = <0>; + #interrupt-cells = <1>; + interrupt-controller; diff --git a/queue-5.19/riscv-dts-microchip-mpfs-remove-bogus-card-detect-delay.patch b/queue-5.19/riscv-dts-microchip-mpfs-remove-bogus-card-detect-delay.patch new file mode 100644 index 00000000000..c28e3135413 --- /dev/null +++ b/queue-5.19/riscv-dts-microchip-mpfs-remove-bogus-card-detect-delay.patch @@ -0,0 +1,56 @@ +From 2b55915d27dcaa35f54bad7925af0a76001079bc Mon Sep 17 00:00:00 2001 +From: Conor Dooley +Date: Sat, 20 Aug 2022 00:14:15 +0100 +Subject: riscv: dts: microchip: mpfs: remove bogus card-detect-delay + +From: Conor Dooley + +commit 2b55915d27dcaa35f54bad7925af0a76001079bc upstream. + +Recent versions of dt-schema warn about a previously undetected +undocumented property: +arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dtb: mmc@20008000: Unevaluated properties are not allowed ('card-detect-delay' was unexpected) + From schema: Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml + +There are no GPIOs connected to MSSIO6B4 pin K3 so adding the common +cd-debounce-delay-ms property makes no sense. The Cadence IP has a +register that sets the card detect delay as "DP * tclk". On MPFS, this +clock frequency is not configurable (it must be 200 MHz) & the FPGA +comes out of reset with this register already set. + +Fixes: bc47b2217f24 ("riscv: dts: microchip: add the sundance polarberry") +Fixes: 0fa6107eca41 ("RISC-V: Initial DTS for Microchip ICICLE board") +Signed-off-by: Conor Dooley +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts | 1 - + arch/riscv/boot/dts/microchip/mpfs-polarberry.dts | 1 - + 2 files changed, 2 deletions(-) + +diff --git a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts +index ee548ab61a2a..f3f87ed2007f 100644 +--- a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts ++++ b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts +@@ -100,7 +100,6 @@ &mmc { + disable-wp; + cap-sd-highspeed; + cap-mmc-highspeed; +- card-detect-delay = <200>; + mmc-ddr-1_8v; + mmc-hs200-1_8v; + sd-uhs-sdr12; +diff --git a/arch/riscv/boot/dts/microchip/mpfs-polarberry.dts b/arch/riscv/boot/dts/microchip/mpfs-polarberry.dts +index dc11bb8fc833..c87cc2d8fe29 100644 +--- a/arch/riscv/boot/dts/microchip/mpfs-polarberry.dts ++++ b/arch/riscv/boot/dts/microchip/mpfs-polarberry.dts +@@ -70,7 +70,6 @@ &mmc { + disable-wp; + cap-sd-highspeed; + cap-mmc-highspeed; +- card-detect-delay = <200>; + mmc-ddr-1_8v; + mmc-hs200-1_8v; + sd-uhs-sdr12; +-- +2.37.2 + diff --git a/queue-5.19/riscv-dts-microchip-mpfs-remove-pci-axi-address-translation-property.patch b/queue-5.19/riscv-dts-microchip-mpfs-remove-pci-axi-address-translation-property.patch new file mode 100644 index 00000000000..4fdb27c2366 --- /dev/null +++ b/queue-5.19/riscv-dts-microchip-mpfs-remove-pci-axi-address-translation-property.patch @@ -0,0 +1,33 @@ +From e4009c5fa77b4356aa37ce002e9f9952dfd7a615 Mon Sep 17 00:00:00 2001 +From: Conor Dooley +Date: Sat, 20 Aug 2022 00:14:16 +0100 +Subject: riscv: dts: microchip: mpfs: remove pci axi address translation property + +From: Conor Dooley + +commit e4009c5fa77b4356aa37ce002e9f9952dfd7a615 upstream. + +An AXI master address translation table property was inadvertently +added to the device tree & this was not caught by dtbs_check at the +time. Remove the property - it should not be in mpfs.dtsi anyway as +it would be more suitable in -fabric.dtsi nor does it actually apply +to the version of the reference design we are using for upstream. + +Link: https://www.microsemi.com/document-portal/doc_download/1245812-polarfire-fpga-and-polarfire-soc-fpga-pci-express-user-guide # Section 1.3.3 +Fixes: 528a5b1f2556 ("riscv: dts: microchip: add new peripherals to icicle kit device tree") +Signed-off-by: Conor Dooley +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/boot/dts/microchip/mpfs.dtsi | 1 - + 1 file changed, 1 deletion(-) + +--- a/arch/riscv/boot/dts/microchip/mpfs.dtsi ++++ b/arch/riscv/boot/dts/microchip/mpfs.dtsi +@@ -446,7 +446,6 @@ + ranges = <0x3000000 0x0 0x8000000 0x20 0x8000000 0x0 0x80000000>; + msi-parent = <&pcie>; + msi-controller; +- microchip,axi-m-atr0 = <0x10 0x0>; + status = "disabled"; + pcie_intc: interrupt-controller { + #address-cells = <0>; diff --git a/queue-5.19/riscv-dts-microchip-mpfs-remove-ti-fifo-depth-property.patch b/queue-5.19/riscv-dts-microchip-mpfs-remove-ti-fifo-depth-property.patch new file mode 100644 index 00000000000..11116545033 --- /dev/null +++ b/queue-5.19/riscv-dts-microchip-mpfs-remove-ti-fifo-depth-property.patch @@ -0,0 +1,58 @@ +From 72a05748cbd285567d69f173f8694e3471b79f20 Mon Sep 17 00:00:00 2001 +From: Conor Dooley +Date: Sat, 20 Aug 2022 00:14:14 +0100 +Subject: riscv: dts: microchip: mpfs: remove ti,fifo-depth property + +From: Conor Dooley + +commit 72a05748cbd285567d69f173f8694e3471b79f20 upstream. + +Recent versions of dt-schema warn about a previously undetected +undocument property on the icicle & polarberry devicetrees: + +arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dtb: ethernet@20112000: ethernet-phy@8: Unevaluated properties are not allowed ('ti,fifo-depth' was unexpected) + From schema: Documentation/devicetree/bindings/net/cdns,macb.yaml + +I know what you're thinking, the binding doesn't look to be the problem +and I agree. I am not sure why a TI vendor property was ever actually +added since it has no meaning... just get rid of it. + +Fixes: bc47b2217f24 ("riscv: dts: microchip: add the sundance polarberry") +Fixes: 0fa6107eca41 ("RISC-V: Initial DTS for Microchip ICICLE board") +Signed-off-by: Conor Dooley +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts | 2 -- + arch/riscv/boot/dts/microchip/mpfs-polarberry.dts | 2 -- + 2 files changed, 4 deletions(-) + +--- a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts ++++ b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts +@@ -84,12 +84,10 @@ + + phy1: ethernet-phy@9 { + reg = <9>; +- ti,fifo-depth = <0x1>; + }; + + phy0: ethernet-phy@8 { + reg = <8>; +- ti,fifo-depth = <0x1>; + }; + }; + +--- a/arch/riscv/boot/dts/microchip/mpfs-polarberry.dts ++++ b/arch/riscv/boot/dts/microchip/mpfs-polarberry.dts +@@ -54,12 +54,10 @@ + + phy1: ethernet-phy@5 { + reg = <5>; +- ti,fifo-depth = <0x01>; + }; + + phy0: ethernet-phy@4 { + reg = <4>; +- ti,fifo-depth = <0x01>; + }; + }; + diff --git a/queue-5.19/scsi-core-fix-passthrough-retry-counter-handling.patch b/queue-5.19/scsi-core-fix-passthrough-retry-counter-handling.patch new file mode 100644 index 00000000000..6bff8dc78fd --- /dev/null +++ b/queue-5.19/scsi-core-fix-passthrough-retry-counter-handling.patch @@ -0,0 +1,52 @@ +From fac8e558da9485e13a0ae0488aa0b8a8c307cd34 Mon Sep 17 00:00:00 2001 +From: Mike Christie +Date: Thu, 11 Aug 2022 20:12:06 -0500 +Subject: scsi: core: Fix passthrough retry counter handling + +From: Mike Christie + +commit fac8e558da9485e13a0ae0488aa0b8a8c307cd34 upstream. + +Passthrough users will set the scsi_cmnd->allowed value and were expecting +up to $allowed retries. The problem is that before: + +commit 6aded12b10e0 ("scsi: core: Remove struct scsi_request") + +we used to set the retries on the scsi_request then copy them over to +scsi_cmnd->allowed in scsi_setup_scsi_cmnd. With that patch we now set +scsi_cmnd->allowed to 0 in scsi_prepare_cmd and overwrite what the +passthrough user set. + +This moves the allowed initialization to after the blk_rq_is_passthrough() +check so it's only done for the non-passthrough path where the ULD +init_command will normally set an allowed value it prefers. + +Link: https://lore.kernel.org/r/20220812011206.9157-1-michael.christie@oracle.com +Fixes: 6aded12b10e0 ("scsi: core: Remove struct scsi_request") +Reviewed-by: Christoph Hellwig +Signed-off-by: Mike Christie +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/scsi_lib.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/scsi/scsi_lib.c ++++ b/drivers/scsi/scsi_lib.c +@@ -1549,7 +1549,6 @@ static blk_status_t scsi_prepare_cmd(str + scsi_init_command(sdev, cmd); + + cmd->eh_eflags = 0; +- cmd->allowed = 0; + cmd->prot_type = 0; + cmd->prot_flags = 0; + cmd->submitter = 0; +@@ -1600,6 +1599,8 @@ static blk_status_t scsi_prepare_cmd(str + return ret; + } + ++ /* Usually overridden by the ULP */ ++ cmd->allowed = 0; + memset(cmd->cmnd, 0, sizeof(cmd->cmnd)); + return scsi_cmd_to_driver(cmd)->init_command(cmd); + } diff --git a/queue-5.19/scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch b/queue-5.19/scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch new file mode 100644 index 00000000000..a35f4276be6 --- /dev/null +++ b/queue-5.19/scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch @@ -0,0 +1,67 @@ +From d957e7ffb2c72410bcc1a514153a46719255a5da Mon Sep 17 00:00:00 2001 +From: Saurabh Sengar +Date: Thu, 4 Aug 2022 08:55:34 -0700 +Subject: scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq + +From: Saurabh Sengar + +commit d957e7ffb2c72410bcc1a514153a46719255a5da upstream. + +storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it +doesn't need to make forward progress under memory pressure. Marking this +workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a +non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following +warning: + +[ 14.506347] ------------[ cut here ]------------ +[ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn +[ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 +[ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu +[ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 +[ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun +[ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 + <-snip-> +[ 14.506408] Call Trace: +[ 14.506412] __flush_work+0xf1/0x1c0 +[ 14.506414] __cancel_work_timer+0x12f/0x1b0 +[ 14.506417] ? kernfs_put+0xf0/0x190 +[ 14.506418] cancel_delayed_work_sync+0x13/0x20 +[ 14.506420] disk_block_events+0x78/0x80 +[ 14.506421] del_gendisk+0x3d/0x2f0 +[ 14.506423] sr_remove+0x28/0x70 +[ 14.506427] device_release_driver_internal+0xef/0x1c0 +[ 14.506428] device_release_driver+0x12/0x20 +[ 14.506429] bus_remove_device+0xe1/0x150 +[ 14.506431] device_del+0x167/0x380 +[ 14.506432] __scsi_remove_device+0x11d/0x150 +[ 14.506433] scsi_remove_device+0x26/0x40 +[ 14.506434] storvsc_remove_lun+0x40/0x60 +[ 14.506436] process_one_work+0x209/0x400 +[ 14.506437] worker_thread+0x34/0x400 +[ 14.506439] kthread+0x121/0x140 +[ 14.506440] ? process_one_work+0x400/0x400 +[ 14.506441] ? kthread_park+0x90/0x90 +[ 14.506443] ret_from_fork+0x35/0x40 +[ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]--- + +Link: https://lore.kernel.org/r/1659628534-17539-1-git-send-email-ssengar@linux.microsoft.com +Fixes: 436ad9413353 ("scsi: storvsc: Allow only one remove lun work item to be issued per lun") +Reviewed-by: Michael Kelley +Signed-off-by: Saurabh Sengar +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/storvsc_drv.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/scsi/storvsc_drv.c ++++ b/drivers/scsi/storvsc_drv.c +@@ -2012,7 +2012,7 @@ static int storvsc_probe(struct hv_devic + */ + host_dev->handle_error_wq = + alloc_ordered_workqueue("storvsc_error_wq_%d", +- WQ_MEM_RECLAIM, ++ 0, + host->host_no); + if (!host_dev->handle_error_wq) { + ret = -ENOMEM; diff --git a/queue-5.19/scsi-ufs-core-enable-link-lost-interrupt.patch b/queue-5.19/scsi-ufs-core-enable-link-lost-interrupt.patch new file mode 100644 index 00000000000..01c85962194 --- /dev/null +++ b/queue-5.19/scsi-ufs-core-enable-link-lost-interrupt.patch @@ -0,0 +1,38 @@ +From 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269 Mon Sep 17 00:00:00 2001 +From: Kiwoong Kim +Date: Tue, 2 Aug 2022 10:42:31 +0900 +Subject: scsi: ufs: core: Enable link lost interrupt + +From: Kiwoong Kim + +commit 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269 upstream. + +Link lost is treated as fatal error with commit c99b9b230149 ("scsi: ufs: +Treat link loss as fatal error"), but the event isn't registered as +interrupt source. Enable it. + +Link: https://lore.kernel.org/r/1659404551-160958-1-git-send-email-kwmad.kim@samsung.com +Fixes: c99b9b230149 ("scsi: ufs: Treat link loss as fatal error") +Reviewed-by: Bart Van Assche +Signed-off-by: Kiwoong Kim +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + include/ufs/ufshci.h | 6 +----- + 1 file changed, 1 insertion(+), 5 deletions(-) + +--- a/include/ufs/ufshci.h ++++ b/include/ufs/ufshci.h +@@ -135,11 +135,7 @@ static inline u32 ufshci_version(u32 maj + + #define UFSHCD_UIC_MASK (UIC_COMMAND_COMPL | UFSHCD_UIC_PWR_MASK) + +-#define UFSHCD_ERROR_MASK (UIC_ERROR |\ +- DEVICE_FATAL_ERROR |\ +- CONTROLLER_FATAL_ERROR |\ +- SYSTEM_BUS_FATAL_ERROR |\ +- CRYPTO_ENGINE_FATAL_ERROR) ++#define UFSHCD_ERROR_MASK (UIC_ERROR | INT_FATAL_ERRORS) + + #define INT_FATAL_ERRORS (DEVICE_FATAL_ERROR |\ + CONTROLLER_FATAL_ERROR |\ diff --git a/queue-5.19/series b/queue-5.19/series index 21aacd8091c..fd667a2607b 100644 --- a/queue-5.19/series +++ b/queue-5.19/series @@ -134,3 +134,24 @@ io_uring-fix-issue-with-io_write-not-always-undoing-sb_start_write.patch mm-hugetlb-fix-hugetlb-not-supporting-softdirty-tracking.patch revert-md-raid-destroy-the-bitmap-after-destroying-the-thread.patch md-call-__md_stop_writes-in-md_stop.patch +arm64-fix-match_list-for-erratum-1286807-on-arm-cortex-a76.patch +binder_alloc-add-missing-mmap_lock-calls-when-using-the-vma.patch +x86-nospec-fix-i386-rsb-stuffing.patch +drm-amdkfd-fix-isa-version-for-the-gc-10.3.7.patch +documentation-abi-mention-retbleed-vulnerability-info-file-for-sysfs.patch +blk-mq-fix-io-hung-due-to-missing-commit_rqs.patch +perf-python-fix-build-when-python_config-is-user-supplied.patch +perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch +perf-x86-intel-ds-fix-precise-store-latency-handling.patch +perf-stat-clear-evsel-reset_group-for-each-stat-run.patch +arm64-fix-rodata-full.patch +arm64-signal-flush-fpsimd-register-state-when-disabling-streaming-mode.patch +arm64-sme-don-t-flush-sve-register-state-when-allocating-sme-storage.patch +arm64-sme-don-t-flush-sve-register-state-when-handling-sme-traps.patch +scsi-ufs-core-enable-link-lost-interrupt.patch +scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch +scsi-core-fix-passthrough-retry-counter-handling.patch +riscv-dts-microchip-mpfs-fix-incorrect-pcie-child-node-name.patch +riscv-dts-microchip-mpfs-remove-ti-fifo-depth-property.patch +riscv-dts-microchip-mpfs-remove-bogus-card-detect-delay.patch +riscv-dts-microchip-mpfs-remove-pci-axi-address-translation-property.patch diff --git a/queue-5.19/x86-nospec-fix-i386-rsb-stuffing.patch b/queue-5.19/x86-nospec-fix-i386-rsb-stuffing.patch new file mode 100644 index 00000000000..5150e2cbe9e --- /dev/null +++ b/queue-5.19/x86-nospec-fix-i386-rsb-stuffing.patch @@ -0,0 +1,50 @@ +From 332924973725e8cdcc783c175f68cf7e162cb9e5 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Fri, 19 Aug 2022 13:01:35 +0200 +Subject: x86/nospec: Fix i386 RSB stuffing + +From: Peter Zijlstra + +commit 332924973725e8cdcc783c175f68cf7e162cb9e5 upstream. + +Turns out that i386 doesn't unconditionally have LFENCE, as such the +loop in __FILL_RETURN_BUFFER isn't actually speculation safe on such +chips. + +Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence") +Reported-by: Ben Hutchings +Signed-off-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/Yv9tj9vbQ9nNlXoY@worktop.programming.kicks-ass.net +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/nospec-branch.h | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/arch/x86/include/asm/nospec-branch.h ++++ b/arch/x86/include/asm/nospec-branch.h +@@ -50,6 +50,7 @@ + * the optimal version - two calls, each with their own speculation + * trap should their return address end up getting used, in a loop. + */ ++#ifdef CONFIG_X86_64 + #define __FILL_RETURN_BUFFER(reg, nr) \ + mov $(nr/2), reg; \ + 771: \ +@@ -60,6 +61,17 @@ + jnz 771b; \ + /* barrier for jnz misprediction */ \ + lfence; ++#else ++/* ++ * i386 doesn't unconditionally have LFENCE, as such it can't ++ * do a loop. ++ */ ++#define __FILL_RETURN_BUFFER(reg, nr) \ ++ .rept nr; \ ++ __FILL_RETURN_SLOT; \ ++ .endr; \ ++ add $(BITS_PER_LONG/8) * nr, %_ASM_SP; ++#endif + + /* + * Stuff a single RSB slot.