From: Greg Kroah-Hartman Date: Sun, 11 Jul 2021 13:14:16 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.4.132~34 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=38d5df3bb2e9a1bab0406fd38e71b65970dbfaa2;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch arm-dts-ux500-fix-led-probing.patch arm_pmu-fix-write-counter-incorrect-in-armv7-big-endian-mode.patch ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch btrfs-send-fix-invalid-path-for-unlink-operations-after-parent-orphanization.patch bus-mhi-wait-for-m2-state-during-system-resume.patch can-bcm-delay-release-of-struct-bcm_op-after-synchronize_rcu.patch can-gw-synchronize-rcu-operations-before-removing-gw-job-entry.patch can-isotp-isotp_release-omit-unintended-hrtimer-restart-on-socket-release.patch can-j1939-j1939_sk_init-set-sock_rcu_free-to-call-sk_destruct-after-rcu-is-done.patch can-peak_pciefd-pucan_handle_status-fix-a-potential-starvation-issue-in-tx-path.patch clk-agilex-stratix10-fix-bypass-representation.patch clk-agilex-stratix10-n5x-fix-how-the-bypass_reg-is-handled.patch clk-agilex-stratix10-remove-noc_clk.patch crypto-ccp-annotate-sev-firmware-file-names.patch crypto-nx-fix-memcpy-over-reading-in-nonce.patch evm-execute-evm_inode_init_security-only-when-an-hmac-key-is-loaded.patch evm-refuse-evm_allow_metadata_writes-only-if-an-hmac-key-is-loaded.patch ext4-cleanup-in-core-orphan-list-if-ext4_truncate-failed-to-get-a-transaction-handle.patch ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch ext4-fix-avefreec-in-find_group_orlov.patch ext4-fix-kernel-infoleak-via-ext4_extent_header.patch ext4-fix-overflow-in-ext4_iomap_alloc.patch ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch ext4-return-error-code-when-ext4_fill_flex_info-fails.patch ext4-use-ext4_grp_locked_error-in-mb_find_extent.patch f2fs-prevent-swap-file-in-lfs-mode.patch fuse-check-connected-before-queueing-on-fpq-io.patch fuse-fix-crash-if-superblock-of-submount-gets-killed-early.patch fuse-fix-crash-in-fuse_dentry_automount-error-path.patch fuse-fix-infinite-loop-in-sget_fc.patch fuse-ignore-pg_workingset-after-stealing.patch fuse-reject-internal-errno.patch iio-accel-bma180-fix-bma25x-bandwidth-register-values.patch iio-frequency-adf4350-disable-reg-and-clk-on-error-in-adf4350_probe.patch iio-light-tcs3472-do-not-free-unallocated-irq.patch iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch kvm-nvmx-handle-split-lock-ac-exceptions-that-happen-in-l2.patch kvm-ppc-book3s-hv-workaround-high-stack-usage-with-clang.patch kvm-x86-mmu-treat-nx-as-used-not-reserved-for-all-tdp-shadow-mmus.patch kvm-x86-mmu-use-mmu-s-role-to-detect-cr4.smep-value-in-nested-npt-walk.patch loop-fix-missing-discard-support-when-using-loop_configure.patch mac80211-remove-iwlwifi-specific-workaround-that-broke-sta-ndp-tx.patch mm-gup-fix-try_grab_compound_head-race-with-split_huge_page.patch perf-smmuv3-don-t-trample-existing-events-with-global-filter.patch powerpc-stacktrace-fix-spurious-stale-traces-in-raise_backtrace_ipi.patch rsi-assign-beacon-rate-settings-to-the-correct-rate_info-descriptor-field.patch rsi-fix-ap-mode-with-wpa-failure-due-to-encrypted-eapol.patch rtc-stm32-fix-unbalanced-clk_disable_unprepare-on-probe-error-path.patch s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch s390-mm-fix-secure-storage-access-exception-handling.patch seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch serial-mvebu-uart-fix-calculation-of-clock-divisor.patch serial-sh-sci-stop-dmaengine-transfer-in-sci_stop_tx.patch serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch serial_cs-remove-wrong-globetrotter.cis-entry.patch ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch sunrpc-fix-the-batch-tasks-count-wraparound.patch sunrpc-should-wake-up-the-privileged-task-firstly.patch tracepoint-add-tracepoint_probe_register_may_exist-for-bpf-tracing.patch tracing-histograms-fix-parsing-of-sym-offset-modifier.patch --- diff --git a/queue-5.10/arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch b/queue-5.10/arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch new file mode 100644 index 00000000000..917947f29cc --- /dev/null +++ b/queue-5.10/arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch @@ -0,0 +1,35 @@ +From 253adffb0e98eaf6da2e7cf73ae68695e21f2f3c Mon Sep 17 00:00:00 2001 +From: Ludovic Desroches +Date: Fri, 25 Oct 2019 10:42:10 +0200 +Subject: ARM: dts: at91: sama5d4: fix pinctrl muxing + +From: Ludovic Desroches + +commit 253adffb0e98eaf6da2e7cf73ae68695e21f2f3c upstream. + +Fix pinctrl muxing, PD28, PD29 and PD31 can be muxed to peripheral A. It +allows to use SCK0, SCK1 and SPI0_NPCS2 signals. + +Signed-off-by: Ludovic Desroches +Fixes: 679f8d92bb01 ("ARM: at91/dt: sama5d4: add pioD pin mux mask and enable pioD") +Cc: stable@vger.kernel.org # v4.4+ +Reviewed-by: Claudiu Beznea +Signed-off-by: Nicolas Ferre +Link: https://lore.kernel.org/r/20191025084210.14726-1-ludovic.desroches@microchip.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/boot/dts/sama5d4.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/boot/dts/sama5d4.dtsi ++++ b/arch/arm/boot/dts/sama5d4.dtsi +@@ -809,7 +809,7 @@ + 0xffffffff 0x3ffcfe7c 0x1c010101 /* pioA */ + 0x7fffffff 0xfffccc3a 0x3f00cc3a /* pioB */ + 0xffffffff 0x3ff83fff 0xff00ffff /* pioC */ +- 0x0003ff00 0x8002a800 0x00000000 /* pioD */ ++ 0xb003ff00 0x8002a800 0x00000000 /* pioD */ + 0xffffffff 0x7fffffff 0x76fff1bf /* pioE */ + >; + diff --git a/queue-5.10/arm-dts-ux500-fix-led-probing.patch b/queue-5.10/arm-dts-ux500-fix-led-probing.patch new file mode 100644 index 00000000000..05bf8048820 --- /dev/null +++ b/queue-5.10/arm-dts-ux500-fix-led-probing.patch @@ -0,0 +1,82 @@ +From 7749510c459c10c431d746a4749e7c9cf2899156 Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Sun, 13 Jun 2021 14:33:56 +0200 +Subject: ARM: dts: ux500: Fix LED probing + +From: Linus Walleij + +commit 7749510c459c10c431d746a4749e7c9cf2899156 upstream. + +The Ux500 HREF LEDs have not been probing properly for a +while as this was introduce: + + ret = of_property_read_u32(np, "color", &led_color); + if (ret) + return ret; + +Since the device tree did not define the new invented color +attribute, probe was failing. + +Define color attributes for the LEDs so they work again. + +Link: https://lore.kernel.org/r/20210613123356.880933-1-linus.walleij@linaro.org +Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") +Cc: stable@vger.kernel.org +Cc: Dan Murphy +Signed-off-by: Linus Walleij +Signed-off-by: Olof Johansson +Signed-off-by: Greg Kroah-Hartman + +diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi +index 83b179692dff..13d216192904 100644 +--- a/arch/arm/boot/dts/ste-href.dtsi ++++ b/arch/arm/boot/dts/ste-href.dtsi +@@ -4,6 +4,7 @@ + */ + + #include ++#include + #include "ste-href-family-pinctrl.dtsi" + + / { +@@ -64,17 +65,20 @@ chan@0 { + reg = <0>; + led-cur = /bits/ 8 <0x2f>; + max-cur = /bits/ 8 <0x5f>; ++ color = ; + linux,default-trigger = "heartbeat"; + }; + chan@1 { + reg = <1>; + led-cur = /bits/ 8 <0x2f>; + max-cur = /bits/ 8 <0x5f>; ++ color = ; + }; + chan@2 { + reg = <2>; + led-cur = /bits/ 8 <0x2f>; + max-cur = /bits/ 8 <0x5f>; ++ color = ; + }; + }; + lp5521@34 { +@@ -88,16 +92,19 @@ chan@0 { + reg = <0>; + led-cur = /bits/ 8 <0x2f>; + max-cur = /bits/ 8 <0x5f>; ++ color = ; + }; + chan@1 { + reg = <1>; + led-cur = /bits/ 8 <0x2f>; + max-cur = /bits/ 8 <0x5f>; ++ color = ; + }; + chan@2 { + reg = <2>; + led-cur = /bits/ 8 <0x2f>; + max-cur = /bits/ 8 <0x5f>; ++ color = ; + }; + }; + bh1780@29 { diff --git a/queue-5.10/arm_pmu-fix-write-counter-incorrect-in-armv7-big-endian-mode.patch b/queue-5.10/arm_pmu-fix-write-counter-incorrect-in-armv7-big-endian-mode.patch new file mode 100644 index 00000000000..43ff14d78e7 --- /dev/null +++ b/queue-5.10/arm_pmu-fix-write-counter-incorrect-in-armv7-big-endian-mode.patch @@ -0,0 +1,73 @@ +From fdbef8c4e68ad423416aa6cc93d1616d6f8ac5b3 Mon Sep 17 00:00:00 2001 +From: Yang Jihong +Date: Fri, 30 Apr 2021 09:26:59 +0800 +Subject: arm_pmu: Fix write counter incorrect in ARMv7 big-endian mode + +From: Yang Jihong + +commit fdbef8c4e68ad423416aa6cc93d1616d6f8ac5b3 upstream. + +Commit 3a95200d3f89 ("arm_pmu: Change API to support 64bit counter values") +changes the input "value" type from 32-bit to 64-bit, which introduces the +following problem: ARMv7 PMU counters is 32-bit width, in big-endian mode, +write counter uses high 32-bit, which writes an incorrect value. + +Before: + + Performance counter stats for 'ls': + + 2.22 msec task-clock # 0.675 CPUs utilized + 0 context-switches # 0.000 K/sec + 0 cpu-migrations # 0.000 K/sec + 49 page-faults # 0.022 M/sec + 2150476593 cycles # 966.663 GHz + 2148588788 instructions # 1.00 insn per cycle + 2147745484 branches # 965435.074 M/sec + 2147508540 branch-misses # 99.99% of all branches + +None of the above hw event counters are correct. + +Solution: + +"value" forcibly converted to 32-bit type before being written to PMU register. + +After: + + Performance counter stats for 'ls': + + 2.09 msec task-clock # 0.681 CPUs utilized + 0 context-switches # 0.000 K/sec + 0 cpu-migrations # 0.000 K/sec + 46 page-faults # 0.022 M/sec + 2807301 cycles # 1.344 GHz + 1060159 instructions # 0.38 insn per cycle + 250496 branches # 119.914 M/sec + 23192 branch-misses # 9.26% of all branches + +Fixes: 3a95200d3f89 ("arm_pmu: Change API to support 64bit counter values") +Cc: +Signed-off-by: Yang Jihong +Acked-by: Mark Rutland +Link: https://lore.kernel.org/r/20210430012659.232110-1-yangjihong1@huawei.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/kernel/perf_event_v7.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm/kernel/perf_event_v7.c ++++ b/arch/arm/kernel/perf_event_v7.c +@@ -773,10 +773,10 @@ static inline void armv7pmu_write_counte + pr_err("CPU%u writing wrong counter %d\n", + smp_processor_id(), idx); + } else if (idx == ARMV7_IDX_CYCLE_COUNTER) { +- asm volatile("mcr p15, 0, %0, c9, c13, 0" : : "r" (value)); ++ asm volatile("mcr p15, 0, %0, c9, c13, 0" : : "r" ((u32)value)); + } else { + armv7_pmnc_select_counter(idx); +- asm volatile("mcr p15, 0, %0, c9, c13, 2" : : "r" (value)); ++ asm volatile("mcr p15, 0, %0, c9, c13, 2" : : "r" ((u32)value)); + } + } + diff --git a/queue-5.10/ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch b/queue-5.10/ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch new file mode 100644 index 00000000000..11e5249eac6 --- /dev/null +++ b/queue-5.10/ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch @@ -0,0 +1,117 @@ +From fb312ac5ccb007e843f982b38d4d6886ba4b32f2 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pali=20Roh=C3=A1r?= +Date: Mon, 31 May 2021 17:41:27 +0300 +Subject: ath9k: Fix kernel NULL pointer dereference during ath_reset_internal() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Pali Rohár + +commit fb312ac5ccb007e843f982b38d4d6886ba4b32f2 upstream. + +I got this crash more times during debugging of PCIe controller and crash +happens somehow at the time when PCIe kernel code started link retraining (as +part of ASPM code) when at the same time PCIe link went down and ath9k probably +executed hw reset procedure. + +Currently I'm not able to reproduce this issue as it looks like to be +some race condition between link training, ASPM, link down and reset +path. And as always, race conditions which depends on more input +parameters are hard to reproduce as it depends on precise timings. + +But it is clear that pointers are zero in this case and should be +properly filled as same code pattern is used in ath9k_stop() function. +Anyway I was able to reproduce this crash by manually triggering ath +reset worker prior putting card up. I created simple patch to export +reset functionality via debugfs and use it to "simulate" of triggering +reset. s proved that NULL-pointer dereference issue is there. + +Function ath9k_hw_reset() is dereferencing chan structure pointer, so it +needs to be non-NULL pointer. + +Function ath9k_stop() already contains code which sets ah->curchan to valid +non-NULL pointer prior calling ath9k_hw_reset() function. + +Add same code pattern also into ath_reset_internal() function to prevent +kernel NULL pointer dereference in ath9k_hw_reset() function. + +This change fixes kernel NULL pointer dereference in ath9k_hw_reset() which +is caused by calling ath9k_hw_reset() from ath_reset_internal() with NULL +chan structure. + + [ 45.334305] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 + [ 45.344417] Mem abort info: + [ 45.347301] ESR = 0x96000005 + [ 45.350448] EC = 0x25: DABT (current EL), IL = 32 bits + [ 45.356166] SET = 0, FnV = 0 + [ 45.359350] EA = 0, S1PTW = 0 + [ 45.362596] Data abort info: + [ 45.365756] ISV = 0, ISS = 0x00000005 + [ 45.369735] CM = 0, WnR = 0 + [ 45.372814] user pgtable: 4k pages, 39-bit VAs, pgdp=000000000685d000 + [ 45.379663] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 + [ 45.388856] Internal error: Oops: 96000005 [#1] SMP + [ 45.393897] Modules linked in: ath9k ath9k_common ath9k_hw + [ 45.399574] CPU: 1 PID: 309 Comm: kworker/u4:2 Not tainted 5.12.0-rc2-dirty #785 + [ 45.414746] Workqueue: phy0 ath_reset_work [ath9k] + [ 45.419713] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) + [ 45.425910] pc : ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] + [ 45.431234] lr : ath9k_hw_reset+0xc0/0x1c48 [ath9k_hw] + [ 45.436548] sp : ffffffc0118dbca0 + [ 45.439961] x29: ffffffc0118dbca0 x28: 0000000000000000 + [ 45.445442] x27: ffffff800dee4080 x26: 0000000000000000 + [ 45.450923] x25: ffffff800df9b9d8 x24: 0000000000000000 + [ 45.456404] x23: ffffffc0115f6000 x22: ffffffc008d0d408 + [ 45.461885] x21: ffffff800dee5080 x20: ffffff800df9b9d8 + [ 45.467366] x19: 0000000000000000 x18: 0000000000000000 + [ 45.472846] x17: 0000000000000000 x16: 0000000000000000 + [ 45.478326] x15: 0000000000000010 x14: ffffffffffffffff + [ 45.483807] x13: ffffffc0918db94f x12: ffffffc011498720 + [ 45.489289] x11: 0000000000000003 x10: ffffffc0114806e0 + [ 45.494770] x9 : ffffffc01014b2ec x8 : 0000000000017fe8 + [ 45.500251] x7 : c0000000ffffefff x6 : 0000000000000001 + [ 45.505733] x5 : 0000000000000000 x4 : 0000000000000000 + [ 45.511213] x3 : 0000000000000000 x2 : ffffff801fece870 + [ 45.516693] x1 : ffffffc00eded000 x0 : 000000000000003f + [ 45.522174] Call trace: + [ 45.524695] ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] + [ 45.529653] ath_reset_internal+0x1a8/0x2b8 [ath9k] + [ 45.534696] ath_reset_work+0x2c/0x40 [ath9k] + [ 45.539198] process_one_work+0x210/0x480 + [ 45.543339] worker_thread+0x5c/0x510 + [ 45.547115] kthread+0x12c/0x130 + [ 45.550445] ret_from_fork+0x10/0x1c + [ 45.554138] Code: 910922c2 9117e021 95ff0398 b4000294 (b9400a61) + [ 45.560430] ---[ end trace 566410ba90b50e8b ]--- + [ 45.565193] Kernel panic - not syncing: Oops: Fatal exception in interrupt + [ 45.572282] SMP: stopping secondary CPUs + [ 45.576331] Kernel Offset: disabled + [ 45.579924] CPU features: 0x00040002,0000200c + [ 45.584416] Memory Limit: none + [ 45.587564] Rebooting in 3 seconds.. + +Signed-off-by: Pali Rohár +Cc: stable@vger.kernel.org +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20210402122653.24014-1-pali@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath/ath9k/main.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/net/wireless/ath/ath9k/main.c ++++ b/drivers/net/wireless/ath/ath9k/main.c +@@ -307,6 +307,11 @@ static int ath_reset_internal(struct ath + hchan = ah->curchan; + } + ++ if (!hchan) { ++ fastcc = false; ++ hchan = ath9k_cmn_get_channel(sc->hw, ah, &sc->cur_chan->chandef); ++ } ++ + if (!ath_prepare_reset(sc)) + fastcc = false; + diff --git a/queue-5.10/btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch b/queue-5.10/btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch new file mode 100644 index 00000000000..e2b903fa9f2 --- /dev/null +++ b/queue-5.10/btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch @@ -0,0 +1,41 @@ +From 6819703f5a365c95488b07066a8744841bf14231 Mon Sep 17 00:00:00 2001 +From: David Sterba +Date: Tue, 7 Jul 2020 18:30:06 +0200 +Subject: btrfs: clear defrag status of a root if starting transaction fails + +From: David Sterba + +commit 6819703f5a365c95488b07066a8744841bf14231 upstream. + +The defrag loop processes leaves in batches and starting transaction for +each. The whole defragmentation on a given root is protected by a bit +but in case the transaction fails, the bit is not cleared + +In case the transaction fails the bit would prevent starting +defragmentation again, so make sure it's cleared. + +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Qu Wenruo +Reviewed-by: Anand Jain +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/transaction.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/transaction.c ++++ b/fs/btrfs/transaction.c +@@ -1382,8 +1382,10 @@ int btrfs_defrag_root(struct btrfs_root + + while (1) { + trans = btrfs_start_transaction(root, 0); +- if (IS_ERR(trans)) +- return PTR_ERR(trans); ++ if (IS_ERR(trans)) { ++ ret = PTR_ERR(trans); ++ break; ++ } + + ret = btrfs_defrag_leaves(trans, root); + diff --git a/queue-5.10/btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch b/queue-5.10/btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch new file mode 100644 index 00000000000..b685c651079 --- /dev/null +++ b/queue-5.10/btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch @@ -0,0 +1,38 @@ +From f2165627319ffd33a6217275e5690b1ab5c45763 Mon Sep 17 00:00:00 2001 +From: David Sterba +Date: Mon, 14 Jun 2021 12:45:18 +0200 +Subject: btrfs: compression: don't try to compress if we don't have enough pages + +From: David Sterba + +commit f2165627319ffd33a6217275e5690b1ab5c45763 upstream. + +The early check if we should attempt compression does not take into +account the number of input pages. It can happen that there's only one +page, eg. a tail page after some ranges of the BTRFS_MAX_UNCOMPRESSED +have been processed, or an isolated page that won't be converted to an +inline extent. + +The single page would be compressed but a later check would drop it +again because the result size must be at least one block shorter than +the input. That can never work with just one page. + +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/inode.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -547,7 +547,7 @@ again: + * inode has not been flagged as nocompress. This flag can + * change at any time if we discover bad compression ratios. + */ +- if (inode_need_compress(BTRFS_I(inode), start, end)) { ++ if (nr_pages > 1 && inode_need_compress(BTRFS_I(inode), start, end)) { + WARN_ON(pages); + pages = kcalloc(nr_pages, sizeof(struct page *), GFP_NOFS); + if (!pages) { diff --git a/queue-5.10/btrfs-send-fix-invalid-path-for-unlink-operations-after-parent-orphanization.patch b/queue-5.10/btrfs-send-fix-invalid-path-for-unlink-operations-after-parent-orphanization.patch new file mode 100644 index 00000000000..481902721db --- /dev/null +++ b/queue-5.10/btrfs-send-fix-invalid-path-for-unlink-operations-after-parent-orphanization.patch @@ -0,0 +1,172 @@ +From d8ac76cdd1755b21e8c008c28d0b7251c0b14986 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Wed, 9 Jun 2021 11:25:03 +0100 +Subject: btrfs: send: fix invalid path for unlink operations after parent orphanization + +From: Filipe Manana + +commit d8ac76cdd1755b21e8c008c28d0b7251c0b14986 upstream. + +During an incremental send operation, when processing the new references +for the current inode, we might send an unlink operation for another inode +that has a conflicting path and has more than one hard link. However this +path was computed and cached before we processed previous new references +for the current inode. We may have orphanized a directory of that path +while processing a previous new reference, in which case the path will +be invalid and cause the receiver process to fail. + +The following reproducer triggers the problem and explains how/why it +happens in its comments: + + $ cat test-send-unlink.sh + #!/bin/bash + + DEV=/dev/sdi + MNT=/mnt/sdi + + mkfs.btrfs -f $DEV >/dev/null + mount $DEV $MNT + + # Create our test files and directory. Inode 259 (file3) has two hard + # links. + touch $MNT/file1 + touch $MNT/file2 + touch $MNT/file3 + + mkdir $MNT/A + ln $MNT/file3 $MNT/A/hard_link + + # Filesystem looks like: + # + # . (ino 256) + # |----- file1 (ino 257) + # |----- file2 (ino 258) + # |----- file3 (ino 259) + # |----- A/ (ino 260) + # |---- hard_link (ino 259) + # + + # Now create the base snapshot, which is going to be the parent snapshot + # for a later incremental send. + btrfs subvolume snapshot -r $MNT $MNT/snap1 + btrfs send -f /tmp/snap1.send $MNT/snap1 + + # Move inode 257 into directory inode 260. This results in computing the + # path for inode 260 as "/A" and caching it. + mv $MNT/file1 $MNT/A/file1 + + # Move inode 258 (file2) into directory inode 260, with a name of + # "hard_link", moving first inode 259 away since it currently has that + # location and name. + mv $MNT/A/hard_link $MNT/tmp + mv $MNT/file2 $MNT/A/hard_link + + # Now rename inode 260 to something else (B for example) and then create + # a hard link for inode 258 that has the old name and location of inode + # 260 ("/A"). + mv $MNT/A $MNT/B + ln $MNT/B/hard_link $MNT/A + + # Filesystem now looks like: + # + # . (ino 256) + # |----- tmp (ino 259) + # |----- file3 (ino 259) + # |----- B/ (ino 260) + # | |---- file1 (ino 257) + # | |---- hard_link (ino 258) + # | + # |----- A (ino 258) + + # Create another snapshot of our subvolume and use it for an incremental + # send. + btrfs subvolume snapshot -r $MNT $MNT/snap2 + btrfs send -f /tmp/snap2.send -p $MNT/snap1 $MNT/snap2 + + # Now unmount the filesystem, create a new one, mount it and try to + # apply both send streams to recreate both snapshots. + umount $DEV + + mkfs.btrfs -f $DEV >/dev/null + + mount $DEV $MNT + + # First add the first snapshot to the new filesystem by applying the + # first send stream. + btrfs receive -f /tmp/snap1.send $MNT + + # The incremental receive operation below used to fail with the + # following error: + # + # ERROR: unlink A/hard_link failed: No such file or directory + # + # This is because when send is processing inode 257, it generates the + # path for inode 260 as "/A", since that inode is its parent in the send + # snapshot, and caches that path. + # + # Later when processing inode 258, it first processes its new reference + # that has the path of "/A", which results in orphanizing inode 260 + # because there is a a path collision. This results in issuing a rename + # operation from "/A" to "/o260-6-0". + # + # Finally when processing the new reference "B/hard_link" for inode 258, + # it notices that it collides with inode 259 (not yet processed, because + # it has a higher inode number), since that inode has the name + # "hard_link" under the directory inode 260. It also checks that inode + # 259 has two hardlinks, so it decides to issue a unlink operation for + # the name "hard_link" for inode 259. However the path passed to the + # unlink operation is "/A/hard_link", which is incorrect since currently + # "/A" does not exists, due to the orphanization of inode 260 mentioned + # before. The path is incorrect because it was computed and cached + # before the orphanization. This results in the receiver to fail with + # the above error. + btrfs receive -f /tmp/snap2.send $MNT + + umount $MNT + +When running the test, it fails like this: + + $ ./test-send-unlink.sh + Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap1' + At subvol /mnt/sdi/snap1 + Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap2' + At subvol /mnt/sdi/snap2 + At subvol snap1 + At snapshot snap2 + ERROR: unlink A/hard_link failed: No such file or directory + +Fix this by recomputing a path before issuing an unlink operation when +processing the new references for the current inode if we previously +have orphanized a directory. + +A test case for fstests will follow soon. + +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/send.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/fs/btrfs/send.c ++++ b/fs/btrfs/send.c +@@ -4080,6 +4080,17 @@ static int process_recorded_refs(struct + if (ret < 0) + goto out; + } else { ++ /* ++ * If we previously orphanized a directory that ++ * collided with a new reference that we already ++ * processed, recompute the current path because ++ * that directory may be part of the path. ++ */ ++ if (orphanized_dir) { ++ ret = refresh_ref_path(sctx, cur); ++ if (ret < 0) ++ goto out; ++ } + ret = send_unlink(sctx, cur->full_path); + if (ret < 0) + goto out; diff --git a/queue-5.10/bus-mhi-wait-for-m2-state-during-system-resume.patch b/queue-5.10/bus-mhi-wait-for-m2-state-during-system-resume.patch new file mode 100644 index 00000000000..63bc9e1f9cb --- /dev/null +++ b/queue-5.10/bus-mhi-wait-for-m2-state-during-system-resume.patch @@ -0,0 +1,71 @@ +From 02b49cd1174527e611768fc2ce0f75a74dfec7ae Mon Sep 17 00:00:00 2001 +From: Baochen Qiang +Date: Mon, 21 Jun 2021 21:46:11 +0530 +Subject: bus: mhi: Wait for M2 state during system resume + +From: Baochen Qiang + +commit 02b49cd1174527e611768fc2ce0f75a74dfec7ae upstream. + +During system resume, MHI host triggers M3->M0 transition and then waits +for target device to enter M0 state. Once done, the device queues a state +change event into ctrl event ring and notifies MHI host by raising an +interrupt, where a tasklet is scheduled to process this event. In most +cases, the tasklet is served timely and wait operation succeeds. + +However, there are cases where CPU is busy and cannot serve this tasklet +for some time. Once delay goes long enough, the device moves itself to M1 +state and also interrupts MHI host after inserting a new state change +event to ctrl ring. Later when CPU finally has time to process the ring, +there will be two events: + +1. For M3->M0 event, which is the first event to be processed queued first. + The tasklet handler serves the event, updates device state to M0 and + wakes up the task. + +2. For M0->M1 event, which is processed later, the tasklet handler + triggers M1->M2 transition and updates device state to M2 directly, + then wakes up the MHI host (if it is still sleeping on this wait queue). + +Note that although MHI host has been woken up while processing the first +event, it may still has no chance to run before the second event is +processed. In other words, MHI host has to keep waiting till timeout +causing the M0 state to be missed. + +kernel log here: +... +Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.911251] mhi 0000:06:00.0: Entered with PM state: M3, MHI state: M3 +Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.917762] mhi 0000:06:00.0: State change event to state: M0 +Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.917767] mhi 0000:06:00.0: State change event to state: M1 +Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4338.788231] mhi 0000:06:00.0: Did not enter M0 state, MHI state: M2, PM state: M2 +... + +Fix this issue by simply adding M2 as a valid state for resume. + +Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 + +Cc: stable@vger.kernel.org +Fixes: 0c6b20a1d720 ("bus: mhi: core: Add support for MHI suspend and resume") +Signed-off-by: Baochen Qiang +Reviewed-by: Hemant Kumar +Reviewed-by: Manivannan Sadhasivam +Link: https://lore.kernel.org/r/20210524040312.14409-1-bqiang@codeaurora.org +[mani: slightly massaged the commit message] +Signed-off-by: Manivannan Sadhasivam +Link: https://lore.kernel.org/r/20210621161616.77524-4-manivannan.sadhasivam@linaro.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/bus/mhi/core/pm.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/bus/mhi/core/pm.c ++++ b/drivers/bus/mhi/core/pm.c +@@ -809,6 +809,7 @@ int mhi_pm_resume(struct mhi_controller + + ret = wait_event_timeout(mhi_cntrl->state_event, + mhi_cntrl->dev_state == MHI_STATE_M0 || ++ mhi_cntrl->dev_state == MHI_STATE_M2 || + MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state), + msecs_to_jiffies(mhi_cntrl->timeout_ms)); + diff --git a/queue-5.10/can-bcm-delay-release-of-struct-bcm_op-after-synchronize_rcu.patch b/queue-5.10/can-bcm-delay-release-of-struct-bcm_op-after-synchronize_rcu.patch new file mode 100644 index 00000000000..46097863a4b --- /dev/null +++ b/queue-5.10/can-bcm-delay-release-of-struct-bcm_op-after-synchronize_rcu.patch @@ -0,0 +1,64 @@ +From d5f9023fa61ee8b94f37a93f08e94b136cf1e463 Mon Sep 17 00:00:00 2001 +From: Thadeu Lima de Souza Cascardo +Date: Sat, 19 Jun 2021 13:18:13 -0300 +Subject: can: bcm: delay release of struct bcm_op after synchronize_rcu() + +From: Thadeu Lima de Souza Cascardo + +commit d5f9023fa61ee8b94f37a93f08e94b136cf1e463 upstream. + +can_rx_register() callbacks may be called concurrently to the call to +can_rx_unregister(). The callbacks and callback data, though, are +protected by RCU and the struct sock reference count. + +So the callback data is really attached to the life of sk, meaning +that it should be released on sk_destruct. However, bcm_remove_op() +calls tasklet_kill(), and RCU callbacks may be called under RCU +softirq, so that cannot be used on kernels before the introduction of +HRTIMER_MODE_SOFT. + +However, bcm_rx_handler() is called under RCU protection, so after +calling can_rx_unregister(), we may call synchronize_rcu() in order to +wait for any RCU read-side critical sections to finish. That is, +bcm_rx_handler() won't be called anymore for those ops. So, we only +free them, after we do that synchronize_rcu(). + +Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") +Link: https://lore.kernel.org/r/20210619161813.2098382-1-cascardo@canonical.com +Cc: linux-stable +Reported-by: syzbot+0f7e7e5e2f4f40fa89c0@syzkaller.appspotmail.com +Reported-by: Norbert Slusarek +Signed-off-by: Thadeu Lima de Souza Cascardo +Acked-by: Oliver Hartkopp +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman + +--- + net/can/bcm.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/net/can/bcm.c ++++ b/net/can/bcm.c +@@ -785,6 +785,7 @@ static int bcm_delete_rx_op(struct list_ + bcm_rx_handler, op); + + list_del(&op->list); ++ synchronize_rcu(); + bcm_remove_op(op); + return 1; /* done */ + } +@@ -1533,9 +1534,13 @@ static int bcm_release(struct socket *so + REGMASK(op->can_id), + bcm_rx_handler, op); + +- bcm_remove_op(op); + } + ++ synchronize_rcu(); ++ ++ list_for_each_entry_safe(op, next, &bo->rx_ops, list) ++ bcm_remove_op(op); ++ + #if IS_ENABLED(CONFIG_PROC_FS) + /* remove procfs entry */ + if (net->can.bcmproc_dir && bo->bcm_proc_read) diff --git a/queue-5.10/can-gw-synchronize-rcu-operations-before-removing-gw-job-entry.patch b/queue-5.10/can-gw-synchronize-rcu-operations-before-removing-gw-job-entry.patch new file mode 100644 index 00000000000..0942fab4d01 --- /dev/null +++ b/queue-5.10/can-gw-synchronize-rcu-operations-before-removing-gw-job-entry.patch @@ -0,0 +1,51 @@ +From fb8696ab14adadb2e3f6c17c18ed26b3ecd96691 Mon Sep 17 00:00:00 2001 +From: Oliver Hartkopp +Date: Fri, 18 Jun 2021 19:36:45 +0200 +Subject: can: gw: synchronize rcu operations before removing gw job entry + +From: Oliver Hartkopp + +commit fb8696ab14adadb2e3f6c17c18ed26b3ecd96691 upstream. + +can_can_gw_rcv() is called under RCU protection, so after calling +can_rx_unregister(), we have to call synchronize_rcu in order to wait +for any RCU read-side critical sections to finish before removing the +kmem_cache entry with the referenced gw job entry. + +Link: https://lore.kernel.org/r/20210618173645.2238-1-socketcan@hartkopp.net +Fixes: c1aabdf379bc ("can-gw: add netlink based CAN routing") +Cc: linux-stable +Signed-off-by: Oliver Hartkopp +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman + +--- + net/can/gw.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/net/can/gw.c ++++ b/net/can/gw.c +@@ -534,6 +534,7 @@ static int cgw_notifier(struct notifier_ + if (gwj->src.dev == dev || gwj->dst.dev == dev) { + hlist_del(&gwj->list); + cgw_unregister_filter(net, gwj); ++ synchronize_rcu(); + kmem_cache_free(cgw_cache, gwj); + } + } +@@ -1092,6 +1093,7 @@ static void cgw_remove_all_jobs(struct n + hlist_for_each_entry_safe(gwj, nx, &net->can.cgw_list, list) { + hlist_del(&gwj->list); + cgw_unregister_filter(net, gwj); ++ synchronize_rcu(); + kmem_cache_free(cgw_cache, gwj); + } + } +@@ -1160,6 +1162,7 @@ static int cgw_remove_job(struct sk_buff + + hlist_del(&gwj->list); + cgw_unregister_filter(net, gwj); ++ synchronize_rcu(); + kmem_cache_free(cgw_cache, gwj); + err = 0; + break; diff --git a/queue-5.10/can-isotp-isotp_release-omit-unintended-hrtimer-restart-on-socket-release.patch b/queue-5.10/can-isotp-isotp_release-omit-unintended-hrtimer-restart-on-socket-release.patch new file mode 100644 index 00000000000..fcc0447def9 --- /dev/null +++ b/queue-5.10/can-isotp-isotp_release-omit-unintended-hrtimer-restart-on-socket-release.patch @@ -0,0 +1,61 @@ +From 14a4696bc3118ba49da28f79280e1d55603aa737 Mon Sep 17 00:00:00 2001 +From: Oliver Hartkopp +Date: Fri, 18 Jun 2021 19:37:13 +0200 +Subject: can: isotp: isotp_release(): omit unintended hrtimer restart on socket release + +From: Oliver Hartkopp + +commit 14a4696bc3118ba49da28f79280e1d55603aa737 upstream. + +When closing the isotp socket, the potentially running hrtimers are +canceled before removing the subscription for CAN identifiers via +can_rx_unregister(). + +This may lead to an unintended (re)start of a hrtimer in +isotp_rcv_cf() and isotp_rcv_fc() in the case that a CAN frame is +received by isotp_rcv() while the subscription removal is processed. + +However, isotp_rcv() is called under RCU protection, so after calling +can_rx_unregister, we may call synchronize_rcu in order to wait for +any RCU read-side critical sections to finish. This prevents the +reception of CAN frames after hrtimer_cancel() and therefore the +unintended (re)start of the hrtimers. + +Link: https://lore.kernel.org/r/20210618173713.2296-1-socketcan@hartkopp.net +Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") +Cc: linux-stable +Signed-off-by: Oliver Hartkopp +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman + +--- + net/can/isotp.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/net/can/isotp.c ++++ b/net/can/isotp.c +@@ -1023,9 +1023,6 @@ static int isotp_release(struct socket * + + lock_sock(sk); + +- hrtimer_cancel(&so->txtimer); +- hrtimer_cancel(&so->rxtimer); +- + /* remove current filters & unregister */ + if (so->bound) { + if (so->ifindex) { +@@ -1037,10 +1034,14 @@ static int isotp_release(struct socket * + SINGLE_MASK(so->rxid), + isotp_rcv, sk); + dev_put(dev); ++ synchronize_rcu(); + } + } + } + ++ hrtimer_cancel(&so->txtimer); ++ hrtimer_cancel(&so->rxtimer); ++ + so->ifindex = 0; + so->bound = 0; + diff --git a/queue-5.10/can-j1939-j1939_sk_init-set-sock_rcu_free-to-call-sk_destruct-after-rcu-is-done.patch b/queue-5.10/can-j1939-j1939_sk_init-set-sock_rcu_free-to-call-sk_destruct-after-rcu-is-done.patch new file mode 100644 index 00000000000..e67a35702ba --- /dev/null +++ b/queue-5.10/can-j1939-j1939_sk_init-set-sock_rcu_free-to-call-sk_destruct-after-rcu-is-done.patch @@ -0,0 +1,52 @@ +From 22c696fed25c63c7f67508309820358b94a96b6d Mon Sep 17 00:00:00 2001 +From: Oleksij Rempel +Date: Thu, 17 Jun 2021 15:06:23 +0200 +Subject: can: j1939: j1939_sk_init(): set SOCK_RCU_FREE to call sk_destruct() after RCU is done + +From: Oleksij Rempel + +commit 22c696fed25c63c7f67508309820358b94a96b6d upstream. + +Set SOCK_RCU_FREE to let RCU to call sk_destruct() on completion. +Without this patch, we will run in to j1939_can_recv() after priv was +freed by j1939_sk_release()->j1939_sk_sock_destruct() + +Fixes: 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") +Link: https://lore.kernel.org/r/20210617130623.12705-1-o.rempel@pengutronix.de +Cc: linux-stable +Reported-by: Thadeu Lima de Souza Cascardo +Reported-by: syzbot+bdf710cfc41c186fdff3@syzkaller.appspotmail.com +Signed-off-by: Oleksij Rempel +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman + +--- + net/can/j1939/main.c | 4 ++++ + net/can/j1939/socket.c | 3 +++ + 2 files changed, 7 insertions(+) + +--- a/net/can/j1939/main.c ++++ b/net/can/j1939/main.c +@@ -193,6 +193,10 @@ static void j1939_can_rx_unregister(stru + can_rx_unregister(dev_net(ndev), ndev, J1939_CAN_ID, J1939_CAN_MASK, + j1939_can_recv, priv); + ++ /* The last reference of priv is dropped by the RCU deferred ++ * j1939_sk_sock_destruct() of the last socket, so we can ++ * safely drop this reference here. ++ */ + j1939_priv_put(priv); + } + +--- a/net/can/j1939/socket.c ++++ b/net/can/j1939/socket.c +@@ -398,6 +398,9 @@ static int j1939_sk_init(struct sock *sk + atomic_set(&jsk->skb_pending, 0); + spin_lock_init(&jsk->sk_session_queue_lock); + INIT_LIST_HEAD(&jsk->sk_session_queue); ++ ++ /* j1939_sk_sock_destruct() depends on SOCK_RCU_FREE flag */ ++ sock_set_flag(sk, SOCK_RCU_FREE); + sk->sk_destruct = j1939_sk_sock_destruct; + sk->sk_protocol = CAN_J1939; + diff --git a/queue-5.10/can-peak_pciefd-pucan_handle_status-fix-a-potential-starvation-issue-in-tx-path.patch b/queue-5.10/can-peak_pciefd-pucan_handle_status-fix-a-potential-starvation-issue-in-tx-path.patch new file mode 100644 index 00000000000..73b2b07e3d6 --- /dev/null +++ b/queue-5.10/can-peak_pciefd-pucan_handle_status-fix-a-potential-starvation-issue-in-tx-path.patch @@ -0,0 +1,41 @@ +From b17233d385d0b6b43ecf81d43008cb1bbb008166 Mon Sep 17 00:00:00 2001 +From: Stephane Grosjean +Date: Wed, 23 Jun 2021 16:26:00 +0200 +Subject: can: peak_pciefd: pucan_handle_status(): fix a potential starvation issue in TX path + +From: Stephane Grosjean + +commit b17233d385d0b6b43ecf81d43008cb1bbb008166 upstream. + +Rather than just indicating that transmission can start, this patch +requires the explicit flushing of the network TX queue when the driver +is informed by the device that it can transmit, next to its +configuration. + +In this way, if frames have already been written by the application, +they will actually be transmitted. + +Fixes: ffd137f7043c ("can: peak/pcie_fd: remove useless code when interface starts") +Link: https://lore.kernel.org/r/20210623142600.149904-1-s.grosjean@peak-system.com +Cc: linux-stable +Signed-off-by: Stephane Grosjean +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/can/peak_canfd/peak_canfd.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/can/peak_canfd/peak_canfd.c ++++ b/drivers/net/can/peak_canfd/peak_canfd.c +@@ -351,8 +351,8 @@ static int pucan_handle_status(struct pe + return err; + } + +- /* start network queue (echo_skb array is empty) */ +- netif_start_queue(ndev); ++ /* wake network queue up (echo_skb array is empty) */ ++ netif_wake_queue(ndev); + + return 0; + } diff --git a/queue-5.10/clk-agilex-stratix10-fix-bypass-representation.patch b/queue-5.10/clk-agilex-stratix10-fix-bypass-representation.patch new file mode 100644 index 00000000000..d4c9806b6ad --- /dev/null +++ b/queue-5.10/clk-agilex-stratix10-fix-bypass-representation.patch @@ -0,0 +1,178 @@ +From 6855ee839699bdabb4b16cf942557fd763bcb1fa Mon Sep 17 00:00:00 2001 +From: Dinh Nguyen +Date: Thu, 10 Jun 2021 21:51:59 -0500 +Subject: clk: agilex/stratix10: fix bypass representation + +From: Dinh Nguyen + +commit 6855ee839699bdabb4b16cf942557fd763bcb1fa upstream. + +Each of these clocks(s2f_usr0/1, sdmmc_clk, gpio_db, emac_ptp, +emac0/1/2) have a bypass setting that can use the boot_clk. The +previous representation was not correct. + +Fix the representation. + +Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform") +Cc: stable@vger.kernel.org +Signed-off-by: Dinh Nguyen +Link: https://lore.kernel.org/r/20210611025201.118799-2-dinguyen@kernel.org +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/clk/socfpga/clk-agilex.c | 57 +++++++++++++++++++++++++++++++-------- + drivers/clk/socfpga/clk-s10.c | 55 ++++++++++++++++++++++++++++++------- + 2 files changed, 91 insertions(+), 21 deletions(-) + +--- a/drivers/clk/socfpga/clk-agilex.c ++++ b/drivers/clk/socfpga/clk-agilex.c +@@ -186,6 +186,41 @@ static const struct clk_parent_data noc_ + .name = "boot_clk", }, + }; + ++static const struct clk_parent_data sdmmc_mux[] = { ++ { .fw_name = "sdmmc_free_clk", ++ .name = "sdmmc_free_clk", }, ++ { .fw_name = "boot_clk", ++ .name = "boot_clk", }, ++}; ++ ++static const struct clk_parent_data s2f_user1_mux[] = { ++ { .fw_name = "s2f_user1_free_clk", ++ .name = "s2f_user1_free_clk", }, ++ { .fw_name = "boot_clk", ++ .name = "boot_clk", }, ++}; ++ ++static const struct clk_parent_data psi_mux[] = { ++ { .fw_name = "psi_ref_free_clk", ++ .name = "psi_ref_free_clk", }, ++ { .fw_name = "boot_clk", ++ .name = "boot_clk", }, ++}; ++ ++static const struct clk_parent_data gpio_db_mux[] = { ++ { .fw_name = "gpio_db_free_clk", ++ .name = "gpio_db_free_clk", }, ++ { .fw_name = "boot_clk", ++ .name = "boot_clk", }, ++}; ++ ++static const struct clk_parent_data emac_ptp_mux[] = { ++ { .fw_name = "emac_ptp_free_clk", ++ .name = "emac_ptp_free_clk", }, ++ { .fw_name = "boot_clk", ++ .name = "boot_clk", }, ++}; ++ + /* clocks in AO (always on) controller */ + static const struct stratix10_pll_clock agilex_pll_clks[] = { + { AGILEX_BOOT_CLK, "boot_clk", boot_mux, ARRAY_SIZE(boot_mux), 0, +@@ -223,7 +258,7 @@ static const struct stratix10_perip_cnt_ + { AGILEX_GPIO_DB_FREE_CLK, "gpio_db_free_clk", NULL, gpio_db_free_mux, + ARRAY_SIZE(gpio_db_free_mux), 0, 0xE0, 0, 0x88, 3}, + { AGILEX_SDMMC_FREE_CLK, "sdmmc_free_clk", NULL, sdmmc_free_mux, +- ARRAY_SIZE(sdmmc_free_mux), 0, 0xE4, 0, 0x88, 4}, ++ ARRAY_SIZE(sdmmc_free_mux), 0, 0xE4, 0, 0, 0}, + { AGILEX_S2F_USER0_FREE_CLK, "s2f_user0_free_clk", NULL, s2f_usr0_free_mux, + ARRAY_SIZE(s2f_usr0_free_mux), 0, 0xE8, 0, 0, 0}, + { AGILEX_S2F_USER1_FREE_CLK, "s2f_user1_free_clk", NULL, s2f_usr1_free_mux, +@@ -265,16 +300,16 @@ static const struct stratix10_gate_clock + 1, 0, 0, 0, 0x94, 27, 0}, + { AGILEX_EMAC2_CLK, "emac2_clk", NULL, emac_mux, ARRAY_SIZE(emac_mux), 0, 0x7C, + 2, 0, 0, 0, 0x94, 28, 0}, +- { AGILEX_EMAC_PTP_CLK, "emac_ptp_clk", "emac_ptp_free_clk", NULL, 1, 0, 0x7C, +- 3, 0, 0, 0, 0, 0, 0}, +- { AGILEX_GPIO_DB_CLK, "gpio_db_clk", "gpio_db_free_clk", NULL, 1, 0, 0x7C, +- 4, 0x98, 0, 16, 0, 0, 0}, +- { AGILEX_SDMMC_CLK, "sdmmc_clk", "sdmmc_free_clk", NULL, 1, 0, 0x7C, +- 5, 0, 0, 0, 0, 0, 4}, +- { AGILEX_S2F_USER1_CLK, "s2f_user1_clk", "s2f_user1_free_clk", NULL, 1, 0, 0x7C, +- 6, 0, 0, 0, 0, 0, 0}, +- { AGILEX_PSI_REF_CLK, "psi_ref_clk", "psi_ref_free_clk", NULL, 1, 0, 0x7C, +- 7, 0, 0, 0, 0, 0, 0}, ++ { AGILEX_EMAC_PTP_CLK, "emac_ptp_clk", NULL, emac_ptp_mux, ARRAY_SIZE(emac_ptp_mux), 0, 0x7C, ++ 3, 0, 0, 0, 0x88, 2, 0}, ++ { AGILEX_GPIO_DB_CLK, "gpio_db_clk", NULL, gpio_db_mux, ARRAY_SIZE(gpio_db_mux), 0, 0x7C, ++ 4, 0x98, 0, 16, 0x88, 3, 0}, ++ { AGILEX_SDMMC_CLK, "sdmmc_clk", NULL, sdmmc_mux, ARRAY_SIZE(sdmmc_mux), 0, 0x7C, ++ 5, 0, 0, 0, 0x88, 4, 4}, ++ { AGILEX_S2F_USER1_CLK, "s2f_user1_clk", NULL, s2f_user1_mux, ARRAY_SIZE(s2f_user1_mux), 0, 0x7C, ++ 6, 0, 0, 0, 0x88, 5, 0}, ++ { AGILEX_PSI_REF_CLK, "psi_ref_clk", NULL, psi_mux, ARRAY_SIZE(psi_mux), 0, 0x7C, ++ 7, 0, 0, 0, 0x88, 6, 0}, + { AGILEX_USB_CLK, "usb_clk", "l4_mp_clk", NULL, 1, 0, 0x7C, + 8, 0, 0, 0, 0, 0, 0}, + { AGILEX_SPI_M_CLK, "spi_m_clk", "l4_mp_clk", NULL, 1, 0, 0x7C, +--- a/drivers/clk/socfpga/clk-s10.c ++++ b/drivers/clk/socfpga/clk-s10.c +@@ -144,6 +144,41 @@ static const struct clk_parent_data mpu_ + .name = "f2s-free-clk", }, + }; + ++static const struct clk_parent_data sdmmc_mux[] = { ++ { .fw_name = "sdmmc_free_clk", ++ .name = "sdmmc_free_clk", }, ++ { .fw_name = "boot_clk", ++ .name = "boot_clk", }, ++}; ++ ++static const struct clk_parent_data s2f_user1_mux[] = { ++ { .fw_name = "s2f_user1_free_clk", ++ .name = "s2f_user1_free_clk", }, ++ { .fw_name = "boot_clk", ++ .name = "boot_clk", }, ++}; ++ ++static const struct clk_parent_data psi_mux[] = { ++ { .fw_name = "psi_ref_free_clk", ++ .name = "psi_ref_free_clk", }, ++ { .fw_name = "boot_clk", ++ .name = "boot_clk", }, ++}; ++ ++static const struct clk_parent_data gpio_db_mux[] = { ++ { .fw_name = "gpio_db_free_clk", ++ .name = "gpio_db_free_clk", }, ++ { .fw_name = "boot_clk", ++ .name = "boot_clk", }, ++}; ++ ++static const struct clk_parent_data emac_ptp_mux[] = { ++ { .fw_name = "emac_ptp_free_clk", ++ .name = "emac_ptp_free_clk", }, ++ { .fw_name = "boot_clk", ++ .name = "boot_clk", }, ++}; ++ + /* clocks in AO (always on) controller */ + static const struct stratix10_pll_clock s10_pll_clks[] = { + { STRATIX10_BOOT_CLK, "boot_clk", boot_mux, ARRAY_SIZE(boot_mux), 0, +@@ -247,16 +282,16 @@ static const struct stratix10_gate_clock + 1, 0, 0, 0, 0xDC, 27, 0}, + { STRATIX10_EMAC2_CLK, "emac2_clk", NULL, emac_mux, ARRAY_SIZE(emac_mux), 0, 0xA4, + 2, 0, 0, 0, 0xDC, 28, 0}, +- { STRATIX10_EMAC_PTP_CLK, "emac_ptp_clk", "emac_ptp_free_clk", NULL, 1, 0, 0xA4, +- 3, 0, 0, 0, 0, 0, 0}, +- { STRATIX10_GPIO_DB_CLK, "gpio_db_clk", "gpio_db_free_clk", NULL, 1, 0, 0xA4, +- 4, 0xE0, 0, 16, 0, 0, 0}, +- { STRATIX10_SDMMC_CLK, "sdmmc_clk", "sdmmc_free_clk", NULL, 1, 0, 0xA4, +- 5, 0, 0, 0, 0, 0, 4}, +- { STRATIX10_S2F_USER1_CLK, "s2f_user1_clk", "s2f_user1_free_clk", NULL, 1, 0, 0xA4, +- 6, 0, 0, 0, 0, 0, 0}, +- { STRATIX10_PSI_REF_CLK, "psi_ref_clk", "psi_ref_free_clk", NULL, 1, 0, 0xA4, +- 7, 0, 0, 0, 0, 0, 0}, ++ { STRATIX10_EMAC_PTP_CLK, "emac_ptp_clk", NULL, emac_ptp_mux, ARRAY_SIZE(emac_ptp_mux), 0, 0xA4, ++ 3, 0, 0, 0, 0xB0, 2, 0}, ++ { STRATIX10_GPIO_DB_CLK, "gpio_db_clk", NULL, gpio_db_mux, ARRAY_SIZE(gpio_db_mux), 0, 0xA4, ++ 4, 0xE0, 0, 16, 0xB0, 3, 0}, ++ { STRATIX10_SDMMC_CLK, "sdmmc_clk", NULL, sdmmc_mux, ARRAY_SIZE(sdmmc_mux), 0, 0xA4, ++ 5, 0, 0, 0, 0xB0, 4, 4}, ++ { STRATIX10_S2F_USER1_CLK, "s2f_user1_clk", NULL, s2f_user1_mux, ARRAY_SIZE(s2f_user1_mux), 0, 0xA4, ++ 6, 0, 0, 0, 0xB0, 5, 0}, ++ { STRATIX10_PSI_REF_CLK, "psi_ref_clk", NULL, psi_mux, ARRAY_SIZE(psi_mux), 0, 0xA4, ++ 7, 0, 0, 0, 0xB0, 6, 0}, + { STRATIX10_USB_CLK, "usb_clk", "l4_mp_clk", NULL, 1, 0, 0xA4, + 8, 0, 0, 0, 0, 0, 0}, + { STRATIX10_SPI_M_CLK, "spi_m_clk", "l4_mp_clk", NULL, 1, 0, 0xA4, diff --git a/queue-5.10/clk-agilex-stratix10-n5x-fix-how-the-bypass_reg-is-handled.patch b/queue-5.10/clk-agilex-stratix10-n5x-fix-how-the-bypass_reg-is-handled.patch new file mode 100644 index 00000000000..96e3800de1a --- /dev/null +++ b/queue-5.10/clk-agilex-stratix10-n5x-fix-how-the-bypass_reg-is-handled.patch @@ -0,0 +1,54 @@ +From dfd1427c3769ba51297777dbb296f1802d72dbf6 Mon Sep 17 00:00:00 2001 +From: Dinh Nguyen +Date: Thu, 10 Jun 2021 21:52:01 -0500 +Subject: clk: agilex/stratix10/n5x: fix how the bypass_reg is handled + +From: Dinh Nguyen + +commit dfd1427c3769ba51297777dbb296f1802d72dbf6 upstream. + +If the bypass_reg is set, then we can return the bypass parent, however, +if there is not a bypass_reg, we need to figure what the correct parent +mux is. + +The previous code never handled the parent mux if there was a +bypass_reg. + +Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform") +Cc: stable@vger.kernel.org +Signed-off-by: Dinh Nguyen +Link: https://lore.kernel.org/r/20210611025201.118799-4-dinguyen@kernel.org +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/clk/socfpga/clk-periph-s10.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + +--- a/drivers/clk/socfpga/clk-periph-s10.c ++++ b/drivers/clk/socfpga/clk-periph-s10.c +@@ -49,16 +49,21 @@ static u8 clk_periclk_get_parent(struct + { + struct socfpga_periph_clk *socfpgaclk = to_periph_clk(hwclk); + u32 clk_src, mask; +- u8 parent; ++ u8 parent = 0; + ++ /* handle the bypass first */ + if (socfpgaclk->bypass_reg) { + mask = (0x1 << socfpgaclk->bypass_shift); + parent = ((readl(socfpgaclk->bypass_reg) & mask) >> + socfpgaclk->bypass_shift); +- } else { ++ if (parent) ++ return parent; ++ } ++ ++ if (socfpgaclk->hw.reg) { + clk_src = readl(socfpgaclk->hw.reg); + parent = (clk_src >> CLK_MGR_FREE_SHIFT) & +- CLK_MGR_FREE_MASK; ++ CLK_MGR_FREE_MASK; + } + return parent; + } diff --git a/queue-5.10/clk-agilex-stratix10-remove-noc_clk.patch b/queue-5.10/clk-agilex-stratix10-remove-noc_clk.patch new file mode 100644 index 00000000000..8b755b4868c --- /dev/null +++ b/queue-5.10/clk-agilex-stratix10-remove-noc_clk.patch @@ -0,0 +1,135 @@ +From efbe21df3e889c0f4bf682c2b7e2465d60b0127c Mon Sep 17 00:00:00 2001 +From: Dinh Nguyen +Date: Thu, 10 Jun 2021 21:51:58 -0500 +Subject: clk: agilex/stratix10: remove noc_clk + +From: Dinh Nguyen + +commit efbe21df3e889c0f4bf682c2b7e2465d60b0127c upstream. + +Early documentation had a noc_clk, but in reality, it's just the +noc_free_clk. Remove the noc_clk clock and just use the noc_free_clk. + +Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform") +Cc: stable@vger.kernel.org +Signed-off-by: Dinh Nguyen +Link: https://lore.kernel.org/r/20210611025201.118799-1-dinguyen@kernel.org +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/clk/socfpga/clk-agilex.c | 32 +++++++++++++++----------------- + drivers/clk/socfpga/clk-s10.c | 32 +++++++++++++++----------------- + 2 files changed, 30 insertions(+), 34 deletions(-) + +--- a/drivers/clk/socfpga/clk-agilex.c ++++ b/drivers/clk/socfpga/clk-agilex.c +@@ -211,11 +211,9 @@ static const struct stratix10_perip_cnt_ + { AGILEX_MPU_FREE_CLK, "mpu_free_clk", NULL, mpu_free_mux, ARRAY_SIZE(mpu_free_mux), + 0, 0x3C, 0, 0, 0}, + { AGILEX_NOC_FREE_CLK, "noc_free_clk", NULL, noc_free_mux, ARRAY_SIZE(noc_free_mux), +- 0, 0x40, 0, 0, 1}, +- { AGILEX_L4_SYS_FREE_CLK, "l4_sys_free_clk", "noc_free_clk", NULL, 1, 0, +- 0, 4, 0, 0}, +- { AGILEX_NOC_CLK, "noc_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), +- 0, 0, 0, 0x30, 1}, ++ 0, 0x40, 0, 0, 0}, ++ { AGILEX_L4_SYS_FREE_CLK, "l4_sys_free_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, ++ 0, 4, 0x30, 1}, + { AGILEX_EMAC_A_FREE_CLK, "emaca_free_clk", NULL, emaca_free_mux, ARRAY_SIZE(emaca_free_mux), + 0, 0xD4, 0, 0x88, 0}, + { AGILEX_EMAC_B_FREE_CLK, "emacb_free_clk", NULL, emacb_free_mux, ARRAY_SIZE(emacb_free_mux), +@@ -241,24 +239,24 @@ static const struct stratix10_gate_clock + 0, 0, 0, 0, 0, 0, 4}, + { AGILEX_MPU_CCU_CLK, "mpu_ccu_clk", "mpu_clk", NULL, 1, 0, 0x24, + 0, 0, 0, 0, 0, 0, 2}, +- { AGILEX_L4_MAIN_CLK, "l4_main_clk", "noc_clk", NULL, 1, 0, 0x24, +- 1, 0x44, 0, 2, 0, 0, 0}, +- { AGILEX_L4_MP_CLK, "l4_mp_clk", "noc_clk", NULL, 1, 0, 0x24, +- 2, 0x44, 8, 2, 0, 0, 0}, ++ { AGILEX_L4_MAIN_CLK, "l4_main_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x24, ++ 1, 0x44, 0, 2, 0x30, 1, 0}, ++ { AGILEX_L4_MP_CLK, "l4_mp_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x24, ++ 2, 0x44, 8, 2, 0x30, 1, 0}, + /* + * The l4_sp_clk feeds a 100 MHz clock to various peripherals, one of them + * being the SP timers, thus cannot get gated. + */ +- { AGILEX_L4_SP_CLK, "l4_sp_clk", "noc_clk", NULL, 1, CLK_IS_CRITICAL, 0x24, +- 3, 0x44, 16, 2, 0, 0, 0}, +- { AGILEX_CS_AT_CLK, "cs_at_clk", "noc_clk", NULL, 1, 0, 0x24, +- 4, 0x44, 24, 2, 0, 0, 0}, +- { AGILEX_CS_TRACE_CLK, "cs_trace_clk", "noc_clk", NULL, 1, 0, 0x24, +- 4, 0x44, 26, 2, 0, 0, 0}, ++ { AGILEX_L4_SP_CLK, "l4_sp_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), CLK_IS_CRITICAL, 0x24, ++ 3, 0x44, 16, 2, 0x30, 1, 0}, ++ { AGILEX_CS_AT_CLK, "cs_at_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x24, ++ 4, 0x44, 24, 2, 0x30, 1, 0}, ++ { AGILEX_CS_TRACE_CLK, "cs_trace_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x24, ++ 4, 0x44, 26, 2, 0x30, 1, 0}, + { AGILEX_CS_PDBG_CLK, "cs_pdbg_clk", "cs_at_clk", NULL, 1, 0, 0x24, + 4, 0x44, 28, 1, 0, 0, 0}, +- { AGILEX_CS_TIMER_CLK, "cs_timer_clk", "noc_clk", NULL, 1, 0, 0x24, +- 5, 0, 0, 0, 0, 0, 0}, ++ { AGILEX_CS_TIMER_CLK, "cs_timer_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x24, ++ 5, 0, 0, 0, 0x30, 1, 0}, + { AGILEX_S2F_USER0_CLK, "s2f_user0_clk", NULL, s2f_usr0_mux, ARRAY_SIZE(s2f_usr0_mux), 0, 0x24, + 6, 0, 0, 0, 0, 0, 0}, + { AGILEX_EMAC0_CLK, "emac0_clk", NULL, emac_mux, ARRAY_SIZE(emac_mux), 0, 0x7C, +--- a/drivers/clk/socfpga/clk-s10.c ++++ b/drivers/clk/socfpga/clk-s10.c +@@ -167,7 +167,7 @@ static const struct stratix10_perip_cnt_ + { STRATIX10_MPU_FREE_CLK, "mpu_free_clk", NULL, mpu_free_mux, ARRAY_SIZE(mpu_free_mux), + 0, 0x48, 0, 0, 0}, + { STRATIX10_NOC_FREE_CLK, "noc_free_clk", NULL, noc_free_mux, ARRAY_SIZE(noc_free_mux), +- 0, 0x4C, 0, 0, 0}, ++ 0, 0x4C, 0, 0x3C, 1}, + { STRATIX10_MAIN_EMACA_CLK, "main_emaca_clk", "main_noc_base_clk", NULL, 1, 0, + 0x50, 0, 0, 0}, + { STRATIX10_MAIN_EMACB_CLK, "main_emacb_clk", "main_noc_base_clk", NULL, 1, 0, +@@ -200,10 +200,8 @@ static const struct stratix10_perip_cnt_ + 0, 0xD4, 0, 0, 0}, + { STRATIX10_PERI_PSI_REF_CLK, "peri_psi_ref_clk", "peri_noc_base_clk", NULL, 1, 0, + 0xD8, 0, 0, 0}, +- { STRATIX10_L4_SYS_FREE_CLK, "l4_sys_free_clk", "noc_free_clk", NULL, 1, 0, +- 0, 4, 0, 0}, +- { STRATIX10_NOC_CLK, "noc_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), +- 0, 0, 0, 0x3C, 1}, ++ { STRATIX10_L4_SYS_FREE_CLK, "l4_sys_free_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, ++ 0, 4, 0x3C, 1}, + { STRATIX10_EMAC_A_FREE_CLK, "emaca_free_clk", NULL, emaca_free_mux, ARRAY_SIZE(emaca_free_mux), + 0, 0, 2, 0xB0, 0}, + { STRATIX10_EMAC_B_FREE_CLK, "emacb_free_clk", NULL, emacb_free_mux, ARRAY_SIZE(emacb_free_mux), +@@ -227,20 +225,20 @@ static const struct stratix10_gate_clock + 0, 0, 0, 0, 0, 0, 4}, + { STRATIX10_MPU_L2RAM_CLK, "mpu_l2ram_clk", "mpu_clk", NULL, 1, 0, 0x30, + 0, 0, 0, 0, 0, 0, 2}, +- { STRATIX10_L4_MAIN_CLK, "l4_main_clk", "noc_clk", NULL, 1, 0, 0x30, +- 1, 0x70, 0, 2, 0, 0, 0}, +- { STRATIX10_L4_MP_CLK, "l4_mp_clk", "noc_clk", NULL, 1, 0, 0x30, +- 2, 0x70, 8, 2, 0, 0, 0}, +- { STRATIX10_L4_SP_CLK, "l4_sp_clk", "noc_clk", NULL, 1, CLK_IS_CRITICAL, 0x30, +- 3, 0x70, 16, 2, 0, 0, 0}, +- { STRATIX10_CS_AT_CLK, "cs_at_clk", "noc_clk", NULL, 1, 0, 0x30, +- 4, 0x70, 24, 2, 0, 0, 0}, +- { STRATIX10_CS_TRACE_CLK, "cs_trace_clk", "noc_clk", NULL, 1, 0, 0x30, +- 4, 0x70, 26, 2, 0, 0, 0}, ++ { STRATIX10_L4_MAIN_CLK, "l4_main_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x30, ++ 1, 0x70, 0, 2, 0x3C, 1, 0}, ++ { STRATIX10_L4_MP_CLK, "l4_mp_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x30, ++ 2, 0x70, 8, 2, 0x3C, 1, 0}, ++ { STRATIX10_L4_SP_CLK, "l4_sp_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), CLK_IS_CRITICAL, 0x30, ++ 3, 0x70, 16, 2, 0x3C, 1, 0}, ++ { STRATIX10_CS_AT_CLK, "cs_at_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x30, ++ 4, 0x70, 24, 2, 0x3C, 1, 0}, ++ { STRATIX10_CS_TRACE_CLK, "cs_trace_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x30, ++ 4, 0x70, 26, 2, 0x3C, 1, 0}, + { STRATIX10_CS_PDBG_CLK, "cs_pdbg_clk", "cs_at_clk", NULL, 1, 0, 0x30, + 4, 0x70, 28, 1, 0, 0, 0}, +- { STRATIX10_CS_TIMER_CLK, "cs_timer_clk", "noc_clk", NULL, 1, 0, 0x30, +- 5, 0, 0, 0, 0, 0, 0}, ++ { STRATIX10_CS_TIMER_CLK, "cs_timer_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x30, ++ 5, 0, 0, 0, 0x3C, 1, 0}, + { STRATIX10_S2F_USER0_CLK, "s2f_user0_clk", NULL, s2f_usr0_mux, ARRAY_SIZE(s2f_usr0_mux), 0, 0x30, + 6, 0, 0, 0, 0, 0, 0}, + { STRATIX10_EMAC0_CLK, "emac0_clk", NULL, emac_mux, ARRAY_SIZE(emac_mux), 0, 0xA4, diff --git a/queue-5.10/crypto-ccp-annotate-sev-firmware-file-names.patch b/queue-5.10/crypto-ccp-annotate-sev-firmware-file-names.patch new file mode 100644 index 00000000000..3dea5a4106c --- /dev/null +++ b/queue-5.10/crypto-ccp-annotate-sev-firmware-file-names.patch @@ -0,0 +1,40 @@ +From c8671c7dc7d51125ab9f651697866bf4a9132277 Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Mon, 26 Apr 2021 10:17:48 +0200 +Subject: crypto: ccp - Annotate SEV Firmware file names + +From: Joerg Roedel + +commit c8671c7dc7d51125ab9f651697866bf4a9132277 upstream. + +Annotate the firmware files CCP might need using MODULE_FIRMWARE(). +This will get them included into an initrd when CCP is also included +there. Otherwise the CCP module will not find its firmware when loaded +before the root-fs is mounted. +This can cause problems when the pre-loaded SEV firmware is too old to +support current SEV and SEV-ES virtualization features. + +Fixes: e93720606efd ("crypto: ccp - Allow SEV firmware to be chosen based on Family and Model") +Cc: stable@vger.kernel.org # v4.20+ +Acked-by: Tom Lendacky +Signed-off-by: Joerg Roedel +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/ccp/sev-dev.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/crypto/ccp/sev-dev.c ++++ b/drivers/crypto/ccp/sev-dev.c +@@ -42,6 +42,10 @@ static int psp_probe_timeout = 5; + module_param(psp_probe_timeout, int, 0644); + MODULE_PARM_DESC(psp_probe_timeout, " default timeout value, in seconds, during PSP device probe"); + ++MODULE_FIRMWARE("amd/amd_sev_fam17h_model0xh.sbin"); /* 1st gen EPYC */ ++MODULE_FIRMWARE("amd/amd_sev_fam17h_model3xh.sbin"); /* 2nd gen EPYC */ ++MODULE_FIRMWARE("amd/amd_sev_fam19h_model0xh.sbin"); /* 3rd gen EPYC */ ++ + static bool psp_dead; + static int psp_timeout; + diff --git a/queue-5.10/crypto-nx-fix-memcpy-over-reading-in-nonce.patch b/queue-5.10/crypto-nx-fix-memcpy-over-reading-in-nonce.patch new file mode 100644 index 00000000000..9e390709951 --- /dev/null +++ b/queue-5.10/crypto-nx-fix-memcpy-over-reading-in-nonce.patch @@ -0,0 +1,32 @@ +From 74c66120fda6596ad57f41e1607b3a5d51ca143d Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Wed, 16 Jun 2021 13:34:59 -0700 +Subject: crypto: nx - Fix memcpy() over-reading in nonce + +From: Kees Cook + +commit 74c66120fda6596ad57f41e1607b3a5d51ca143d upstream. + +Fix typo in memcpy() where size should be CTR_RFC3686_NONCE_SIZE. + +Fixes: 030f4e968741 ("crypto: nx - Fix reentrancy bugs") +Cc: stable@vger.kernel.org +Signed-off-by: Kees Cook +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/nx/nx-aes-ctr.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/crypto/nx/nx-aes-ctr.c ++++ b/drivers/crypto/nx/nx-aes-ctr.c +@@ -118,7 +118,7 @@ static int ctr3686_aes_nx_crypt(struct s + struct nx_crypto_ctx *nx_ctx = crypto_skcipher_ctx(tfm); + u8 iv[16]; + +- memcpy(iv, nx_ctx->priv.ctr.nonce, CTR_RFC3686_IV_SIZE); ++ memcpy(iv, nx_ctx->priv.ctr.nonce, CTR_RFC3686_NONCE_SIZE); + memcpy(iv + CTR_RFC3686_NONCE_SIZE, req->iv, CTR_RFC3686_IV_SIZE); + iv[12] = iv[13] = iv[14] = 0; + iv[15] = 1; diff --git a/queue-5.10/evm-execute-evm_inode_init_security-only-when-an-hmac-key-is-loaded.patch b/queue-5.10/evm-execute-evm_inode_init_security-only-when-an-hmac-key-is-loaded.patch new file mode 100644 index 00000000000..dbe2aee0147 --- /dev/null +++ b/queue-5.10/evm-execute-evm_inode_init_security-only-when-an-hmac-key-is-loaded.patch @@ -0,0 +1,58 @@ +From 9eea2904292c2d8fa98df141d3bf7c41ec9dc1b5 Mon Sep 17 00:00:00 2001 +From: Roberto Sassu +Date: Fri, 14 May 2021 17:27:42 +0200 +Subject: evm: Execute evm_inode_init_security() only when an HMAC key is loaded + +From: Roberto Sassu + +commit 9eea2904292c2d8fa98df141d3bf7c41ec9dc1b5 upstream. + +evm_inode_init_security() requires an HMAC key to calculate the HMAC on +initial xattrs provided by LSMs. However, it checks generically whether a +key has been loaded, including also public keys, which is not correct as +public keys are not suitable to calculate the HMAC. + +Originally, support for signature verification was introduced to verify a +possibly immutable initial ram disk, when no new files are created, and to +switch to HMAC for the root filesystem. By that time, an HMAC key should +have been loaded and usable to calculate HMACs for new files. + +More recently support for requiring an HMAC key was removed from the +kernel, so that signature verification can be used alone. Since this is a +legitimate use case, evm_inode_init_security() should not return an error +when no HMAC key has been loaded. + +This patch fixes this problem by replacing the evm_key_loaded() check with +a check of the EVM_INIT_HMAC flag in evm_initialized. + +Fixes: 26ddabfe96b ("evm: enable EVM when X509 certificate is loaded") +Signed-off-by: Roberto Sassu +Cc: stable@vger.kernel.org # 4.5.x +Signed-off-by: Mimi Zohar +Signed-off-by: Greg Kroah-Hartman + +--- + security/integrity/evm/evm_main.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/security/integrity/evm/evm_main.c ++++ b/security/integrity/evm/evm_main.c +@@ -521,7 +521,7 @@ void evm_inode_post_setattr(struct dentr + } + + /* +- * evm_inode_init_security - initializes security.evm ++ * evm_inode_init_security - initializes security.evm HMAC value + */ + int evm_inode_init_security(struct inode *inode, + const struct xattr *lsm_xattr, +@@ -530,7 +530,8 @@ int evm_inode_init_security(struct inode + struct evm_xattr *xattr_data; + int rc; + +- if (!evm_key_loaded() || !evm_protected_xattr(lsm_xattr->name)) ++ if (!(evm_initialized & EVM_INIT_HMAC) || ++ !evm_protected_xattr(lsm_xattr->name)) + return 0; + + xattr_data = kzalloc(sizeof(*xattr_data), GFP_NOFS); diff --git a/queue-5.10/evm-refuse-evm_allow_metadata_writes-only-if-an-hmac-key-is-loaded.patch b/queue-5.10/evm-refuse-evm_allow_metadata_writes-only-if-an-hmac-key-is-loaded.patch new file mode 100644 index 00000000000..b93970a1ce2 --- /dev/null +++ b/queue-5.10/evm-refuse-evm_allow_metadata_writes-only-if-an-hmac-key-is-loaded.patch @@ -0,0 +1,84 @@ +From 9acc89d31f0c94c8e573ed61f3e4340bbd526d0c Mon Sep 17 00:00:00 2001 +From: Roberto Sassu +Date: Fri, 14 May 2021 17:27:44 +0200 +Subject: evm: Refuse EVM_ALLOW_METADATA_WRITES only if an HMAC key is loaded + +From: Roberto Sassu + +commit 9acc89d31f0c94c8e573ed61f3e4340bbd526d0c upstream. + +EVM_ALLOW_METADATA_WRITES is an EVM initialization flag that can be set to +temporarily disable metadata verification until all xattrs/attrs necessary +to verify an EVM portable signature are copied to the file. This flag is +cleared when EVM is initialized with an HMAC key, to avoid that the HMAC is +calculated on unverified xattrs/attrs. + +Currently EVM unnecessarily denies setting this flag if EVM is initialized +with a public key, which is not a concern as it cannot be used to trust +xattrs/attrs updates. This patch removes this limitation. + +Fixes: ae1ba1676b88e ("EVM: Allow userland to permit modification of EVM-protected metadata") +Signed-off-by: Roberto Sassu +Cc: stable@vger.kernel.org # 4.16.x +Signed-off-by: Mimi Zohar +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/ABI/testing/evm | 26 ++++++++++++++++++++++++-- + security/integrity/evm/evm_secfs.c | 8 ++++---- + 2 files changed, 28 insertions(+), 6 deletions(-) + +--- a/Documentation/ABI/testing/evm ++++ b/Documentation/ABI/testing/evm +@@ -49,8 +49,30 @@ Description: + modification of EVM-protected metadata and + disable all further modification of policy + +- Note that once a key has been loaded, it will no longer be +- possible to enable metadata modification. ++ Echoing a value is additive, the new value is added to the ++ existing initialization flags. ++ ++ For example, after:: ++ ++ echo 2 >/evm ++ ++ another echo can be performed:: ++ ++ echo 1 >/evm ++ ++ and the resulting value will be 3. ++ ++ Note that once an HMAC key has been loaded, it will no longer ++ be possible to enable metadata modification. Signaling that an ++ HMAC key has been loaded will clear the corresponding flag. ++ For example, if the current value is 6 (2 and 4 set):: ++ ++ echo 1 >/evm ++ ++ will set the new value to 3 (4 cleared). ++ ++ Loading an HMAC key is the only way to disable metadata ++ modification. + + Until key loading has been signaled EVM can not create + or validate the 'security.evm' xattr, but returns +--- a/security/integrity/evm/evm_secfs.c ++++ b/security/integrity/evm/evm_secfs.c +@@ -80,12 +80,12 @@ static ssize_t evm_write_key(struct file + if (!i || (i & ~EVM_INIT_MASK) != 0) + return -EINVAL; + +- /* Don't allow a request to freshly enable metadata writes if +- * keys are loaded. ++ /* ++ * Don't allow a request to enable metadata writes if ++ * an HMAC key is loaded. + */ + if ((i & EVM_ALLOW_METADATA_WRITES) && +- ((evm_initialized & EVM_KEY_MASK) != 0) && +- !(evm_initialized & EVM_ALLOW_METADATA_WRITES)) ++ (evm_initialized & EVM_INIT_HMAC) != 0) + return -EPERM; + + if (i & EVM_INIT_HMAC) { diff --git a/queue-5.10/ext4-cleanup-in-core-orphan-list-if-ext4_truncate-failed-to-get-a-transaction-handle.patch b/queue-5.10/ext4-cleanup-in-core-orphan-list-if-ext4_truncate-failed-to-get-a-transaction-handle.patch new file mode 100644 index 00000000000..db90e904858 --- /dev/null +++ b/queue-5.10/ext4-cleanup-in-core-orphan-list-if-ext4_truncate-failed-to-get-a-transaction-handle.patch @@ -0,0 +1,54 @@ +From b9a037b7f3c401d3c63e0423e56aef606b1ffaaf Mon Sep 17 00:00:00 2001 +From: Zhang Yi +Date: Fri, 7 May 2021 15:19:04 +0800 +Subject: ext4: cleanup in-core orphan list if ext4_truncate() failed to get a transaction handle + +From: Zhang Yi + +commit b9a037b7f3c401d3c63e0423e56aef606b1ffaaf upstream. + +In ext4_orphan_cleanup(), if ext4_truncate() failed to get a transaction +handle, it didn't remove the inode from the in-core orphan list, which +may probably trigger below error dump in ext4_destroy_inode() during the +final iput() and could lead to memory corruption on the later orphan +list changes. + + EXT4-fs (sda): Inode 6291467 (00000000b8247c67): orphan list check failed! + 00000000b8247c67: 0001f30a 00000004 00000000 00000023 ............#... + 00000000e24cde71: 00000006 014082a3 00000000 00000000 ......@......... + 0000000072c6a5ee: 00000000 00000000 00000000 00000000 ................ + ... + +This patch fix this by cleanup in-core orphan list manually if +ext4_truncate() return error. + +Cc: stable@kernel.org +Signed-off-by: Zhang Yi +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20210507071904.160808-1-yi.zhang@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/super.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -3099,8 +3099,15 @@ static void ext4_orphan_cleanup(struct s + inode_lock(inode); + truncate_inode_pages(inode->i_mapping, inode->i_size); + ret = ext4_truncate(inode); +- if (ret) ++ if (ret) { ++ /* ++ * We need to clean up the in-core orphan list ++ * manually if ext4_truncate() failed to get a ++ * transaction handle. ++ */ ++ ext4_orphan_del(NULL, inode); + ext4_std_error(inode->i_sb, ret); ++ } + inode_unlock(inode); + nr_truncates++; + } else { diff --git a/queue-5.10/ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch b/queue-5.10/ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch new file mode 100644 index 00000000000..012b20b7f2a --- /dev/null +++ b/queue-5.10/ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch @@ -0,0 +1,35 @@ +From 4fb7c70a889ead2e91e184895ac6e5354b759135 Mon Sep 17 00:00:00 2001 +From: Zhang Yi +Date: Sat, 22 May 2021 18:30:45 +0800 +Subject: ext4: correct the cache_nr in tracepoint ext4_es_shrink_exit + +From: Zhang Yi + +commit 4fb7c70a889ead2e91e184895ac6e5354b759135 upstream. + +The cache_cnt parameter of tracepoint ext4_es_shrink_exit means the +remaining cache count after shrink, but now it is the cache count before +shrink, fix it by read sbi->s_extent_cache_cnt again. + +Fixes: 1ab6c4997e04 ("fs: convert fs shrinkers to new scan/count API") +Cc: stable@vger.kernel.org # 3.12+ +Signed-off-by: Zhang Yi +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20210522103045.690103-3-yi.zhang@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/extents_status.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/ext4/extents_status.c ++++ b/fs/ext4/extents_status.c +@@ -1579,6 +1579,7 @@ static unsigned long ext4_es_scan(struct + + nr_shrunk = __es_shrink(sbi, nr_to_scan, NULL); + ++ ret = percpu_counter_read_positive(&sbi->s_es_stats.es_stats_shk_cnt); + trace_ext4_es_shrink_scan_exit(sbi->s_sb, nr_shrunk, ret); + return nr_shrunk; + } diff --git a/queue-5.10/ext4-fix-avefreec-in-find_group_orlov.patch b/queue-5.10/ext4-fix-avefreec-in-find_group_orlov.patch new file mode 100644 index 00000000000..7ef671d39fc --- /dev/null +++ b/queue-5.10/ext4-fix-avefreec-in-find_group_orlov.patch @@ -0,0 +1,64 @@ +From c89849cc0259f3d33624cc3bd127685c3c0fa25d Mon Sep 17 00:00:00 2001 +From: Pan Dong +Date: Tue, 25 May 2021 15:36:56 +0800 +Subject: ext4: fix avefreec in find_group_orlov + +From: Pan Dong + +commit c89849cc0259f3d33624cc3bd127685c3c0fa25d upstream. + +The avefreec should be average free clusters instead +of average free blocks, otherwize Orlov's allocator +will not work properly when bigalloc enabled. + +Cc: stable@kernel.org +Signed-off-by: Pan Dong +Link: https://lore.kernel.org/r/20210525073656.31594-1-pandong.peter@bytedance.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/ialloc.c | 11 +++++------ + 1 file changed, 5 insertions(+), 6 deletions(-) + +--- a/fs/ext4/ialloc.c ++++ b/fs/ext4/ialloc.c +@@ -402,7 +402,7 @@ static void get_orlov_stats(struct super + * + * We always try to spread first-level directories. + * +- * If there are blockgroups with both free inodes and free blocks counts ++ * If there are blockgroups with both free inodes and free clusters counts + * not worse than average we return one with smallest directory count. + * Otherwise we simply return a random group. + * +@@ -411,7 +411,7 @@ static void get_orlov_stats(struct super + * It's OK to put directory into a group unless + * it has too many directories already (max_dirs) or + * it has too few free inodes left (min_inodes) or +- * it has too few free blocks left (min_blocks) or ++ * it has too few free clusters left (min_clusters) or + * Parent's group is preferred, if it doesn't satisfy these + * conditions we search cyclically through the rest. If none + * of the groups look good we just look for a group with more +@@ -427,7 +427,7 @@ static int find_group_orlov(struct super + ext4_group_t real_ngroups = ext4_get_groups_count(sb); + int inodes_per_group = EXT4_INODES_PER_GROUP(sb); + unsigned int freei, avefreei, grp_free; +- ext4_fsblk_t freeb, avefreec; ++ ext4_fsblk_t freec, avefreec; + unsigned int ndirs; + int max_dirs, min_inodes; + ext4_grpblk_t min_clusters; +@@ -446,9 +446,8 @@ static int find_group_orlov(struct super + + freei = percpu_counter_read_positive(&sbi->s_freeinodes_counter); + avefreei = freei / ngroups; +- freeb = EXT4_C2B(sbi, +- percpu_counter_read_positive(&sbi->s_freeclusters_counter)); +- avefreec = freeb; ++ freec = percpu_counter_read_positive(&sbi->s_freeclusters_counter); ++ avefreec = freec; + do_div(avefreec, ngroups); + ndirs = percpu_counter_read_positive(&sbi->s_dirs_counter); + diff --git a/queue-5.10/ext4-fix-kernel-infoleak-via-ext4_extent_header.patch b/queue-5.10/ext4-fix-kernel-infoleak-via-ext4_extent_header.patch new file mode 100644 index 00000000000..3c432fc531b --- /dev/null +++ b/queue-5.10/ext4-fix-kernel-infoleak-via-ext4_extent_header.patch @@ -0,0 +1,51 @@ +From ce3aba43599f0b50adbebff133df8d08a3d5fffe Mon Sep 17 00:00:00 2001 +From: Anirudh Rayabharam +Date: Fri, 7 May 2021 00:26:54 +0530 +Subject: ext4: fix kernel infoleak via ext4_extent_header + +From: Anirudh Rayabharam + +commit ce3aba43599f0b50adbebff133df8d08a3d5fffe upstream. + +Initialize eh_generation of struct ext4_extent_header to prevent leaking +info to userspace. Fixes KMSAN kernel-infoleak bug reported by syzbot at: +http://syzkaller.appspot.com/bug?id=78e9ad0e6952a3ca16e8234724b2fa92d041b9b8 + +Cc: stable@kernel.org +Reported-by: syzbot+2dcfeaf8cb49b05e8f1a@syzkaller.appspotmail.com +Fixes: a86c61812637 ("[PATCH] ext3: add extent map support") +Signed-off-by: Anirudh Rayabharam +Link: https://lore.kernel.org/r/20210506185655.7118-1-mail@anirudhrb.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/extents.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/ext4/extents.c ++++ b/fs/ext4/extents.c +@@ -825,6 +825,7 @@ void ext4_ext_tree_init(handle_t *handle + eh->eh_entries = 0; + eh->eh_magic = EXT4_EXT_MAGIC; + eh->eh_max = cpu_to_le16(ext4_ext_space_root(inode, 0)); ++ eh->eh_generation = 0; + ext4_mark_inode_dirty(handle, inode); + } + +@@ -1090,6 +1091,7 @@ static int ext4_ext_split(handle_t *hand + neh->eh_max = cpu_to_le16(ext4_ext_space_block(inode, 0)); + neh->eh_magic = EXT4_EXT_MAGIC; + neh->eh_depth = 0; ++ neh->eh_generation = 0; + + /* move remainder of path[depth] to the new leaf */ + if (unlikely(path[depth].p_hdr->eh_entries != +@@ -1167,6 +1169,7 @@ static int ext4_ext_split(handle_t *hand + neh->eh_magic = EXT4_EXT_MAGIC; + neh->eh_max = cpu_to_le16(ext4_ext_space_block_idx(inode, 0)); + neh->eh_depth = cpu_to_le16(depth - i); ++ neh->eh_generation = 0; + fidx = EXT_FIRST_INDEX(neh); + fidx->ei_block = border; + ext4_idx_store_pblock(fidx, oldblock); diff --git a/queue-5.10/ext4-fix-overflow-in-ext4_iomap_alloc.patch b/queue-5.10/ext4-fix-overflow-in-ext4_iomap_alloc.patch new file mode 100644 index 00000000000..ff6b800892e --- /dev/null +++ b/queue-5.10/ext4-fix-overflow-in-ext4_iomap_alloc.patch @@ -0,0 +1,36 @@ +From d0b040f5f2557b2f507c01e88ad8cff424fdc6a9 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Mon, 12 Apr 2021 12:23:33 +0200 +Subject: ext4: fix overflow in ext4_iomap_alloc() + +From: Jan Kara + +commit d0b040f5f2557b2f507c01e88ad8cff424fdc6a9 upstream. + +A code in iomap alloc may overflow block number when converting it to +byte offset. Luckily this is mostly harmless as we will just use more +expensive method of writing using unwritten extents even though we are +writing beyond i_size. + +Cc: stable@kernel.org +Fixes: 378f32bab371 ("ext4: introduce direct I/O write using iomap infrastructure") +Signed-off-by: Jan Kara +Link: https://lore.kernel.org/r/20210412102333.2676-4-jack@suse.cz +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/inode.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -3419,7 +3419,7 @@ retry: + * i_disksize out to i_size. This could be beyond where direct I/O is + * happening and thus expose allocated blocks to direct I/O reads. + */ +- else if ((map->m_lblk * (1 << blkbits)) >= i_size_read(inode)) ++ else if (((loff_t)map->m_lblk << blkbits) >= i_size_read(inode)) + m_flags = EXT4_GET_BLOCKS_CREATE; + else if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) + m_flags = EXT4_GET_BLOCKS_IO_CREATE_EXT; diff --git a/queue-5.10/ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch b/queue-5.10/ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch new file mode 100644 index 00000000000..7714382a220 --- /dev/null +++ b/queue-5.10/ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch @@ -0,0 +1,37 @@ +From e5e7010e5444d923e4091cafff61d05f2d19cada Mon Sep 17 00:00:00 2001 +From: Zhang Yi +Date: Sat, 22 May 2021 18:30:44 +0800 +Subject: ext4: remove check for zero nr_to_scan in ext4_es_scan() + +From: Zhang Yi + +commit e5e7010e5444d923e4091cafff61d05f2d19cada upstream. + +After converting fs shrinkers to new scan/count API, we are no longer +pass zero nr_to_scan parameter to detect the number of objects to free, +just remove this check. + +Fixes: 1ab6c4997e04 ("fs: convert fs shrinkers to new scan/count API") +Cc: stable@vger.kernel.org # 3.12+ +Signed-off-by: Zhang Yi +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20210522103045.690103-2-yi.zhang@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/extents_status.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/fs/ext4/extents_status.c ++++ b/fs/ext4/extents_status.c +@@ -1574,9 +1574,6 @@ static unsigned long ext4_es_scan(struct + ret = percpu_counter_read_positive(&sbi->s_es_stats.es_stats_shk_cnt); + trace_ext4_es_shrink_scan_enter(sbi->s_sb, nr_to_scan, ret); + +- if (!nr_to_scan) +- return ret; +- + nr_shrunk = __es_shrink(sbi, nr_to_scan, NULL); + + ret = percpu_counter_read_positive(&sbi->s_es_stats.es_stats_shk_cnt); diff --git a/queue-5.10/ext4-return-error-code-when-ext4_fill_flex_info-fails.patch b/queue-5.10/ext4-return-error-code-when-ext4_fill_flex_info-fails.patch new file mode 100644 index 00000000000..df5bfe61336 --- /dev/null +++ b/queue-5.10/ext4-return-error-code-when-ext4_fill_flex_info-fails.patch @@ -0,0 +1,37 @@ +From 8f6840c4fd1e7bd715e403074fb161c1a04cda73 Mon Sep 17 00:00:00 2001 +From: Yang Yingliang +Date: Mon, 10 May 2021 19:10:51 +0800 +Subject: ext4: return error code when ext4_fill_flex_info() fails + +From: Yang Yingliang + +commit 8f6840c4fd1e7bd715e403074fb161c1a04cda73 upstream. + +After commit c89128a00838 ("ext4: handle errors on +ext4_commit_super"), 'ret' may be set to 0 before calling +ext4_fill_flex_info(), if ext4_fill_flex_info() fails ext4_mount() +doesn't return error code, it makes 'root' is null which causes crash +in legacy_get_tree(). + +Fixes: c89128a00838 ("ext4: handle errors on ext4_commit_super") +Reported-by: Hulk Robot +Cc: # v4.18+ +Signed-off-by: Yang Yingliang +Link: https://lore.kernel.org/r/20210510111051.55650-1-yangyingliang@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/super.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -5046,6 +5046,7 @@ no_journal: + ext4_msg(sb, KERN_ERR, + "unable to initialize " + "flex_bg meta info!"); ++ ret = -ENOMEM; + goto failed_mount6; + } + diff --git a/queue-5.10/ext4-use-ext4_grp_locked_error-in-mb_find_extent.patch b/queue-5.10/ext4-use-ext4_grp_locked_error-in-mb_find_extent.patch new file mode 100644 index 00000000000..955b9e0c033 --- /dev/null +++ b/queue-5.10/ext4-use-ext4_grp_locked_error-in-mb_find_extent.patch @@ -0,0 +1,48 @@ +From cd84bbbac12a173a381a64c6ec8b76a5277b87b5 Mon Sep 17 00:00:00 2001 +From: Stephen Brennan +Date: Wed, 23 Jun 2021 16:21:14 -0700 +Subject: ext4: use ext4_grp_locked_error in mb_find_extent + +From: Stephen Brennan + +commit cd84bbbac12a173a381a64c6ec8b76a5277b87b5 upstream. + +Commit 5d1b1b3f492f ("ext4: fix BUG when calling ext4_error with locked +block group") introduces ext4_grp_locked_error to handle unlocking a +group in error cases. Otherwise, there is a possibility of a sleep while +atomic. However, since 43c73221b3b1 ("ext4: replace BUG_ON with WARN_ON +in mb_find_extent()"), mb_find_extent() has contained a ext4_error() +call while a group spinlock is held. Replace this with +ext4_grp_locked_error. + +Fixes: 43c73221b3b1 ("ext4: replace BUG_ON with WARN_ON in mb_find_extent()") +Cc: # 4.14+ +Signed-off-by: Stephen Brennan +Reviewed-by: Lukas Czerner +Reviewed-by: Junxiao Bi +Link: https://lore.kernel.org/r/20210623232114.34457-1-stephen.s.brennan@oracle.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/mballoc.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -1597,10 +1597,11 @@ static int mb_find_extent(struct ext4_bu + if (ex->fe_start + ex->fe_len > EXT4_CLUSTERS_PER_GROUP(e4b->bd_sb)) { + /* Should never happen! (but apparently sometimes does?!?) */ + WARN_ON(1); +- ext4_error(e4b->bd_sb, "corruption or bug in mb_find_extent " +- "block=%d, order=%d needed=%d ex=%u/%d/%d@%u", +- block, order, needed, ex->fe_group, ex->fe_start, +- ex->fe_len, ex->fe_logical); ++ ext4_grp_locked_error(e4b->bd_sb, e4b->bd_group, 0, 0, ++ "corruption or bug in mb_find_extent " ++ "block=%d, order=%d needed=%d ex=%u/%d/%d@%u", ++ block, order, needed, ex->fe_group, ex->fe_start, ++ ex->fe_len, ex->fe_logical); + ex->fe_len = 0; + ex->fe_start = 0; + ex->fe_group = 0; diff --git a/queue-5.10/f2fs-prevent-swap-file-in-lfs-mode.patch b/queue-5.10/f2fs-prevent-swap-file-in-lfs-mode.patch new file mode 100644 index 00000000000..380a14bb6be --- /dev/null +++ b/queue-5.10/f2fs-prevent-swap-file-in-lfs-mode.patch @@ -0,0 +1,44 @@ +From d927ccfccb009ede24448d69c08b12e7c8a6979b Mon Sep 17 00:00:00 2001 +From: Shin'ichiro Kawasaki +Date: Mon, 10 May 2021 20:24:44 +0900 +Subject: f2fs: Prevent swap file in LFS mode + +From: Shin'ichiro Kawasaki + +commit d927ccfccb009ede24448d69c08b12e7c8a6979b upstream. + +The kernel writes to swap files on f2fs directly without the assistance +of the filesystem. This direct write by kernel can be non-sequential +even when the f2fs is in LFS mode. Such non-sequential write conflicts +with the LFS semantics. Especially when f2fs is set up on zoned block +devices, the non-sequential write causes unaligned write command errors. + +To avoid the non-sequential writes to swap files, prevent swap file +activation when the filesystem is in LFS mode. + +Fixes: 4969c06a0d83 ("f2fs: support swap file w/ DIO") +Signed-off-by: Shin'ichiro Kawasaki +Cc: stable@vger.kernel.org # v5.10+ +Reviewed-by: Chao Yu +Signed-off-by: Jaegeuk Kim +Signed-off-by: Greg Kroah-Hartman + +--- + fs/f2fs/data.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/fs/f2fs/data.c ++++ b/fs/f2fs/data.c +@@ -4112,6 +4112,12 @@ static int f2fs_swap_activate(struct swa + if (f2fs_readonly(F2FS_I_SB(inode)->sb)) + return -EROFS; + ++ if (f2fs_lfs_mode(F2FS_I_SB(inode))) { ++ f2fs_err(F2FS_I_SB(inode), ++ "Swapfile not supported in LFS mode"); ++ return -EINVAL; ++ } ++ + ret = f2fs_convert_inline_inode(inode); + if (ret) + return ret; diff --git a/queue-5.10/fuse-check-connected-before-queueing-on-fpq-io.patch b/queue-5.10/fuse-check-connected-before-queueing-on-fpq-io.patch new file mode 100644 index 00000000000..b89442e37ff --- /dev/null +++ b/queue-5.10/fuse-check-connected-before-queueing-on-fpq-io.patch @@ -0,0 +1,58 @@ +From 80ef08670d4c28a06a3de954bd350368780bcfef Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi +Date: Tue, 22 Jun 2021 09:15:35 +0200 +Subject: fuse: check connected before queueing on fpq->io + +From: Miklos Szeredi + +commit 80ef08670d4c28a06a3de954bd350368780bcfef upstream. + +A request could end up on the fpq->io list after fuse_abort_conn() has +reset fpq->connected and aborted requests on that list: + +Thread-1 Thread-2 +======== ======== +->fuse_simple_request() ->shutdown + ->__fuse_request_send() + ->queue_request() ->fuse_abort_conn() +->fuse_dev_do_read() ->acquire(fpq->lock) + ->wait_for(fpq->lock) ->set err to all req's in fpq->io + ->release(fpq->lock) + ->acquire(fpq->lock) + ->add req to fpq->io + +After the userspace copy is done the request will be ended, but +req->out.h.error will remain uninitialized. Also the copy might block +despite being already aborted. + +Fix both issues by not allowing the request to be queued on the fpq->io +list after fuse_abort_conn() has processed this list. + +Reported-by: Pradeep P V K +Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts") +Cc: # v4.2 +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/dev.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/fs/fuse/dev.c ++++ b/fs/fuse/dev.c +@@ -1276,6 +1276,15 @@ static ssize_t fuse_dev_do_read(struct f + goto restart; + } + spin_lock(&fpq->lock); ++ /* ++ * Must not put request on fpq->io queue after having been shut down by ++ * fuse_abort_conn() ++ */ ++ if (!fpq->connected) { ++ req->out.h.error = err = -ECONNABORTED; ++ goto out_end; ++ ++ } + list_add(&req->list, &fpq->io); + spin_unlock(&fpq->lock); + cs->req = req; diff --git a/queue-5.10/fuse-fix-crash-if-superblock-of-submount-gets-killed-early.patch b/queue-5.10/fuse-fix-crash-if-superblock-of-submount-gets-killed-early.patch new file mode 100644 index 00000000000..74db0d77440 --- /dev/null +++ b/queue-5.10/fuse-fix-crash-if-superblock-of-submount-gets-killed-early.patch @@ -0,0 +1,52 @@ +From e3a43f2a95393000778f8f302d48795add2fc4a8 Mon Sep 17 00:00:00 2001 +From: Greg Kurz +Date: Fri, 4 Jun 2021 18:11:51 +0200 +Subject: fuse: Fix crash if superblock of submount gets killed early + +From: Greg Kurz + +commit e3a43f2a95393000778f8f302d48795add2fc4a8 upstream. + +As soon as fuse_dentry_automount() does up_write(&sb->s_umount), the +superblock can theoretically be killed. If this happens before the +submount was added to the &fc->mounts list, fuse_mount_remove() later +crashes in list_del_init() because it assumes the submount to be +already there. + +Add the submount before dropping sb->s_umount to fix the inconsistency. +It is okay to nest fc->killsb under sb->s_umount, we already do this +on the ->kill_sb() path. + +Signed-off-by: Greg Kurz +Fixes: bf109c64040f ("fuse: implement crossmounts") +Cc: stable@vger.kernel.org # v5.10+ +Reviewed-by: Max Reitz +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/dir.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/fs/fuse/dir.c ++++ b/fs/fuse/dir.c +@@ -347,15 +347,15 @@ static struct vfsmount *fuse_dentry_auto + goto out_put_sb; + } + ++ down_write(&fc->killsb); ++ list_add_tail(&fm->fc_entry, &fc->mounts); ++ up_write(&fc->killsb); ++ + sb->s_flags |= SB_ACTIVE; + fsc->root = dget(sb->s_root); + /* We are done configuring the superblock, so unlock it */ + up_write(&sb->s_umount); + +- down_write(&fc->killsb); +- list_add_tail(&fm->fc_entry, &fc->mounts); +- up_write(&fc->killsb); +- + /* Create the submount */ + mnt = vfs_create_mount(fsc); + if (IS_ERR(mnt)) { diff --git a/queue-5.10/fuse-fix-crash-in-fuse_dentry_automount-error-path.patch b/queue-5.10/fuse-fix-crash-in-fuse_dentry_automount-error-path.patch new file mode 100644 index 00000000000..800f32aa411 --- /dev/null +++ b/queue-5.10/fuse-fix-crash-in-fuse_dentry_automount-error-path.patch @@ -0,0 +1,59 @@ +From d92d88f0568e97c437eeb79d9c9609bd8277406f Mon Sep 17 00:00:00 2001 +From: Greg Kurz +Date: Fri, 4 Jun 2021 18:11:50 +0200 +Subject: fuse: Fix crash in fuse_dentry_automount() error path + +From: Greg Kurz + +commit d92d88f0568e97c437eeb79d9c9609bd8277406f upstream. + +If fuse_fill_super_submount() returns an error, the error path +triggers a crash: + +[ 26.206673] BUG: kernel NULL pointer dereference, address: 0000000000000000 +[...] +[ 26.226362] RIP: 0010:__list_del_entry_valid+0x25/0x90 +[...] +[ 26.247938] Call Trace: +[ 26.248300] fuse_mount_remove+0x2c/0x70 [fuse] +[ 26.248892] virtio_kill_sb+0x22/0x160 [virtiofs] +[ 26.249487] deactivate_locked_super+0x36/0xa0 +[ 26.250077] fuse_dentry_automount+0x178/0x1a0 [fuse] + +The crash happens because fuse_mount_remove() assumes that the FUSE +mount was already added to list under the FUSE connection, but this +only done after fuse_fill_super_submount() has returned success. + +This means that until fuse_fill_super_submount() has returned success, +the FUSE mount isn't actually owned by the superblock. We should thus +reclaim ownership by clearing sb->s_fs_info, which will skip the call +to fuse_mount_remove(), and perform rollback, like virtio_fs_get_tree() +already does for the root sb. + +Fixes: bf109c64040f ("fuse: implement crossmounts") +Cc: stable@vger.kernel.org # v5.10+ +Signed-off-by: Greg Kurz +Reviewed-by: Max Reitz +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/dir.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/fs/fuse/dir.c ++++ b/fs/fuse/dir.c +@@ -340,8 +340,12 @@ static struct vfsmount *fuse_dentry_auto + + /* Initialize superblock, making @mp_fi its root */ + err = fuse_fill_super_submount(sb, mp_fi); +- if (err) ++ if (err) { ++ fuse_conn_put(fc); ++ kfree(fm); ++ sb->s_fs_info = NULL; + goto out_put_sb; ++ } + + sb->s_flags |= SB_ACTIVE; + fsc->root = dget(sb->s_root); diff --git a/queue-5.10/fuse-fix-infinite-loop-in-sget_fc.patch b/queue-5.10/fuse-fix-infinite-loop-in-sget_fc.patch new file mode 100644 index 00000000000..d72362c178b --- /dev/null +++ b/queue-5.10/fuse-fix-infinite-loop-in-sget_fc.patch @@ -0,0 +1,58 @@ +From e4a9ccdd1c03b3dc58214874399d24331ea0a3ab Mon Sep 17 00:00:00 2001 +From: Greg Kurz +Date: Fri, 4 Jun 2021 18:11:52 +0200 +Subject: fuse: Fix infinite loop in sget_fc() + +From: Greg Kurz + +commit e4a9ccdd1c03b3dc58214874399d24331ea0a3ab upstream. + +We don't set the SB_BORN flag on submounts. This is wrong as these +superblocks are then considered as partially constructed or dying +in the rest of the code and can break some assumptions. + +One such case is when you have a virtiofs filesystem with submounts +and you try to mount it again : virtio_fs_get_tree() tries to obtain +a superblock with sget_fc(). The logic in sget_fc() is to loop until +it has either found an existing matching superblock with SB_BORN set +or to create a brand new one. It is assumed that a superblock without +SB_BORN is transient and the loop is restarted. Forgetting to set +SB_BORN on submounts hence causes sget_fc() to retry forever. + +Setting SB_BORN requires special care, i.e. a write barrier for +super_cache_count() which can check SB_BORN without taking any lock. +We should call vfs_get_tree() to deal with that but this requires +to have a proper ->get_tree() implementation for submounts, which +is a bigger piece of work. Go for a simple bug fix in the meatime. + +Fixes: bf109c64040f ("fuse: implement crossmounts") +Cc: stable@vger.kernel.org # v5.10+ +Signed-off-by: Greg Kurz +Reviewed-by: Max Reitz +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/dir.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/fs/fuse/dir.c ++++ b/fs/fuse/dir.c +@@ -353,6 +353,17 @@ static struct vfsmount *fuse_dentry_auto + + sb->s_flags |= SB_ACTIVE; + fsc->root = dget(sb->s_root); ++ ++ /* ++ * FIXME: setting SB_BORN requires a write barrier for ++ * super_cache_count(). We should actually come ++ * up with a proper ->get_tree() implementation ++ * for submounts and call vfs_get_tree() to take ++ * care of the write barrier. ++ */ ++ smp_wmb(); ++ sb->s_flags |= SB_BORN; ++ + /* We are done configuring the superblock, so unlock it */ + up_write(&sb->s_umount); + diff --git a/queue-5.10/fuse-ignore-pg_workingset-after-stealing.patch b/queue-5.10/fuse-ignore-pg_workingset-after-stealing.patch new file mode 100644 index 00000000000..0129cfff3b8 --- /dev/null +++ b/queue-5.10/fuse-ignore-pg_workingset-after-stealing.patch @@ -0,0 +1,41 @@ +From b89ecd60d38ec042d63bdb376c722a16f92bcb88 Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi +Date: Fri, 18 Jun 2021 21:16:42 +0200 +Subject: fuse: ignore PG_workingset after stealing + +From: Miklos Szeredi + +commit b89ecd60d38ec042d63bdb376c722a16f92bcb88 upstream. + +Fix the "fuse: trying to steal weird page" warning. + +Description from Johannes Weiner: + + "Think of it as similar to PG_active. It's just another usage/heat + indicator of file and anon pages on the reclaim LRU that, unlike + PG_active, persists across deactivation and even reclaim (we store it in + the page cache / swapper cache tree until the page refaults). + + So if fuse accepts pages that can legally have PG_active set, + PG_workingset is fine too." + +Reported-by: Thomas Lindroth +Fixes: 1899ad18c607 ("mm: workingset: tell cache transitions from workingset thrashing") +Cc: # v4.20 +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/dev.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/fuse/dev.c ++++ b/fs/fuse/dev.c +@@ -783,6 +783,7 @@ static int fuse_check_page(struct page * + 1 << PG_uptodate | + 1 << PG_lru | + 1 << PG_active | ++ 1 << PG_workingset | + 1 << PG_reclaim | + 1 << PG_waiters))) { + dump_page(page, "fuse: trying to steal weird page"); diff --git a/queue-5.10/fuse-reject-internal-errno.patch b/queue-5.10/fuse-reject-internal-errno.patch new file mode 100644 index 00000000000..0a95a3d40e5 --- /dev/null +++ b/queue-5.10/fuse-reject-internal-errno.patch @@ -0,0 +1,32 @@ +From 49221cf86d18bb66fe95d3338cb33bd4b9880ca5 Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi +Date: Tue, 22 Jun 2021 09:15:35 +0200 +Subject: fuse: reject internal errno + +From: Miklos Szeredi + +commit 49221cf86d18bb66fe95d3338cb33bd4b9880ca5 upstream. + +Don't allow userspace to report errors that could be kernel-internal. + +Reported-by: Anatoly Trosinenko +Fixes: 334f485df85a ("[PATCH] FUSE - device functions") +Cc: # v2.6.14 +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/dev.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/fuse/dev.c ++++ b/fs/fuse/dev.c +@@ -1871,7 +1871,7 @@ static ssize_t fuse_dev_do_write(struct + } + + err = -EINVAL; +- if (oh.error <= -1000 || oh.error > 0) ++ if (oh.error <= -512 || oh.error > 0) + goto copy_finish; + + spin_lock(&fpq->lock); diff --git a/queue-5.10/iio-accel-bma180-fix-bma25x-bandwidth-register-values.patch b/queue-5.10/iio-accel-bma180-fix-bma25x-bandwidth-register-values.patch new file mode 100644 index 00000000000..7ebec5be03c --- /dev/null +++ b/queue-5.10/iio-accel-bma180-fix-bma25x-bandwidth-register-values.patch @@ -0,0 +1,95 @@ +From 8090d67421ddab0ae932abab5a60200598bf0bbb Mon Sep 17 00:00:00 2001 +From: Stephan Gerhold +Date: Wed, 26 May 2021 11:44:07 +0200 +Subject: iio: accel: bma180: Fix BMA25x bandwidth register values +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Stephan Gerhold + +commit 8090d67421ddab0ae932abab5a60200598bf0bbb upstream. + +According to the BMA253 datasheet [1] and BMA250 datasheet [2] the +bandwidth value for BMA25x should be set as 01xxx: + + "Settings 00xxx result in a bandwidth of 7.81 Hz; [...] + It is recommended [...] to use the range from ´01000b´ to ´01111b´ + only in order to be compatible with future products." + +However, at the moment the drivers sets bandwidth values from 0 to 6, +which is not recommended and always results into 7.81 Hz bandwidth +according to the datasheet. + +Fix this by introducing a bw_offset = 8 = 01000b for BMA25x, +so the additional bit is always set for BMA25x. + +[1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bma253-ds000.pdf +[2]: https://datasheet.octopart.com/BMA250-Bosch-datasheet-15540103.pdf + +Cc: Peter Meerwald +Fixes: 2017cff24cc0 ("iio:bma180: Add BMA250 chip support") +Signed-off-by: Stephan Gerhold +Reviewed-by: Linus Walleij +Link: https://lore.kernel.org/r/20210526094408.34298-2-stephan@gerhold.net +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/accel/bma180.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/drivers/iio/accel/bma180.c ++++ b/drivers/iio/accel/bma180.c +@@ -55,7 +55,7 @@ struct bma180_part_info { + + u8 int_reset_reg, int_reset_mask; + u8 sleep_reg, sleep_mask; +- u8 bw_reg, bw_mask; ++ u8 bw_reg, bw_mask, bw_offset; + u8 scale_reg, scale_mask; + u8 power_reg, power_mask, lowpower_val; + u8 int_enable_reg, int_enable_mask; +@@ -127,6 +127,7 @@ struct bma180_part_info { + + #define BMA250_RANGE_MASK GENMASK(3, 0) /* Range of accel values */ + #define BMA250_BW_MASK GENMASK(4, 0) /* Accel bandwidth */ ++#define BMA250_BW_OFFSET 8 + #define BMA250_SUSPEND_MASK BIT(7) /* chip will sleep */ + #define BMA250_LOWPOWER_MASK BIT(6) + #define BMA250_DATA_INTEN_MASK BIT(4) +@@ -143,6 +144,7 @@ struct bma180_part_info { + + #define BMA254_RANGE_MASK GENMASK(3, 0) /* Range of accel values */ + #define BMA254_BW_MASK GENMASK(4, 0) /* Accel bandwidth */ ++#define BMA254_BW_OFFSET 8 + #define BMA254_SUSPEND_MASK BIT(7) /* chip will sleep */ + #define BMA254_LOWPOWER_MASK BIT(6) + #define BMA254_DATA_INTEN_MASK BIT(4) +@@ -283,7 +285,8 @@ static int bma180_set_bw(struct bma180_d + for (i = 0; i < data->part_info->num_bw; ++i) { + if (data->part_info->bw_table[i] == val) { + ret = bma180_set_bits(data, data->part_info->bw_reg, +- data->part_info->bw_mask, i); ++ data->part_info->bw_mask, ++ i + data->part_info->bw_offset); + if (ret) { + dev_err(&data->client->dev, + "failed to set bandwidth\n"); +@@ -876,6 +879,7 @@ static const struct bma180_part_info bma + .sleep_mask = BMA250_SUSPEND_MASK, + .bw_reg = BMA250_BW_REG, + .bw_mask = BMA250_BW_MASK, ++ .bw_offset = BMA250_BW_OFFSET, + .scale_reg = BMA250_RANGE_REG, + .scale_mask = BMA250_RANGE_MASK, + .power_reg = BMA250_POWER_REG, +@@ -905,6 +909,7 @@ static const struct bma180_part_info bma + .sleep_mask = BMA254_SUSPEND_MASK, + .bw_reg = BMA254_BW_REG, + .bw_mask = BMA254_BW_MASK, ++ .bw_offset = BMA254_BW_OFFSET, + .scale_reg = BMA254_RANGE_REG, + .scale_mask = BMA254_RANGE_MASK, + .power_reg = BMA254_POWER_REG, diff --git a/queue-5.10/iio-frequency-adf4350-disable-reg-and-clk-on-error-in-adf4350_probe.patch b/queue-5.10/iio-frequency-adf4350-disable-reg-and-clk-on-error-in-adf4350_probe.patch new file mode 100644 index 00000000000..be910a13230 --- /dev/null +++ b/queue-5.10/iio-frequency-adf4350-disable-reg-and-clk-on-error-in-adf4350_probe.patch @@ -0,0 +1,39 @@ +From c8cc4cf60b000fb9f4b29bed131fb6cf1fe42d67 Mon Sep 17 00:00:00 2001 +From: Yang Yingliang +Date: Tue, 1 Jun 2021 22:26:05 +0800 +Subject: iio: frequency: adf4350: disable reg and clk on error in adf4350_probe() + +From: Yang Yingliang + +commit c8cc4cf60b000fb9f4b29bed131fb6cf1fe42d67 upstream. + +Disable reg and clk when devm_gpiod_get_optional() fails in adf4350_probe(). + +Fixes:4a89d2f47ccd ("iio: adf4350: Convert to use GPIO descriptor") +Reported-by: Hulk Robot +Signed-off-by: Yang Yingliang +Reviewed-by: Linus Walleij +Link: https://lore.kernel.org/r/20210601142605.3613605-1-yangyingliang@huawei.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/frequency/adf4350.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/iio/frequency/adf4350.c ++++ b/drivers/iio/frequency/adf4350.c +@@ -563,8 +563,10 @@ static int adf4350_probe(struct spi_devi + + st->lock_detect_gpiod = devm_gpiod_get_optional(&spi->dev, NULL, + GPIOD_IN); +- if (IS_ERR(st->lock_detect_gpiod)) +- return PTR_ERR(st->lock_detect_gpiod); ++ if (IS_ERR(st->lock_detect_gpiod)) { ++ ret = PTR_ERR(st->lock_detect_gpiod); ++ goto error_disable_reg; ++ } + + if (pdata->power_up_frequency) { + ret = adf4350_set_freq(st, pdata->power_up_frequency); diff --git a/queue-5.10/iio-light-tcs3472-do-not-free-unallocated-irq.patch b/queue-5.10/iio-light-tcs3472-do-not-free-unallocated-irq.patch new file mode 100644 index 00000000000..2194e751c99 --- /dev/null +++ b/queue-5.10/iio-light-tcs3472-do-not-free-unallocated-irq.patch @@ -0,0 +1,55 @@ +From 7cd04c863f9e1655d607705455e7714f24451984 Mon Sep 17 00:00:00 2001 +From: frank zago +Date: Mon, 26 Apr 2021 21:20:17 -0500 +Subject: iio: light: tcs3472: do not free unallocated IRQ + +From: frank zago + +commit 7cd04c863f9e1655d607705455e7714f24451984 upstream. + +Allocating an IRQ is conditional to the IRQ existence, but freeing it +was not. If no IRQ was allocate, the driver would still try to free +IRQ 0. Add the missing checks. + +This fixes the following trace when the driver is removed: + +[ 100.667788] Trying to free already-free IRQ 0 +[ 100.667793] WARNING: CPU: 0 PID: 2315 at kernel/irq/manage.c:1826 free_irq+0x1fd/0x370 +... +[ 100.667914] Call Trace: +[ 100.667920] tcs3472_remove+0x3a/0x90 [tcs3472] +[ 100.667927] i2c_device_remove+0x2b/0xa0 + +Signed-off-by: frank zago +Link: https://lore.kernel.org/r/20210427022017.19314-2-frank@zago.net +Fixes: 9d2f715d592e ("iio: light: tcs3472: support out-of-threshold events") +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/light/tcs3472.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/iio/light/tcs3472.c ++++ b/drivers/iio/light/tcs3472.c +@@ -531,7 +531,8 @@ static int tcs3472_probe(struct i2c_clie + return 0; + + free_irq: +- free_irq(client->irq, indio_dev); ++ if (client->irq) ++ free_irq(client->irq, indio_dev); + buffer_cleanup: + iio_triggered_buffer_cleanup(indio_dev); + return ret; +@@ -559,7 +560,8 @@ static int tcs3472_remove(struct i2c_cli + struct iio_dev *indio_dev = i2c_get_clientdata(client); + + iio_device_unregister(indio_dev); +- free_irq(client->irq, indio_dev); ++ if (client->irq) ++ free_irq(client->irq, indio_dev); + iio_triggered_buffer_cleanup(indio_dev); + tcs3472_powerdown(iio_priv(indio_dev)); + diff --git a/queue-5.10/iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch b/queue-5.10/iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch new file mode 100644 index 00000000000..7cefdc9677c --- /dev/null +++ b/queue-5.10/iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch @@ -0,0 +1,51 @@ +From 71b33f6f93ef9462c84560e2236ed22209d26a58 Mon Sep 17 00:00:00 2001 +From: Oliver Lang +Date: Thu, 10 Jun 2021 15:46:18 +0200 +Subject: iio: ltr501: ltr501_read_ps(): add missing endianness conversion + +From: Oliver Lang + +commit 71b33f6f93ef9462c84560e2236ed22209d26a58 upstream. + +The PS ADC Channel data is spread over 2 registers in little-endian +form. This patch adds the missing endianness conversion. + +Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver") +Signed-off-by: Oliver Lang +Reviewed-by: Andy Shevchenko +Signed-off-by: Marc Kleine-Budde +Tested-by: Nikita Travkin # ltr559 +Link: https://lore.kernel.org/r/20210610134619.2101372-4-mkl@pengutronix.de +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/light/ltr501.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/iio/light/ltr501.c ++++ b/drivers/iio/light/ltr501.c +@@ -409,18 +409,19 @@ static int ltr501_read_als(const struct + + static int ltr501_read_ps(const struct ltr501_data *data) + { +- int ret, status; ++ __le16 status; ++ int ret; + + ret = ltr501_drdy(data, LTR501_STATUS_PS_RDY); + if (ret < 0) + return ret; + + ret = regmap_bulk_read(data->regmap, LTR501_PS_DATA, +- &status, 2); ++ &status, sizeof(status)); + if (ret < 0) + return ret; + +- return status; ++ return le16_to_cpu(status); + } + + static int ltr501_read_intr_prst(const struct ltr501_data *data, diff --git a/queue-5.10/iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch b/queue-5.10/iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch new file mode 100644 index 00000000000..db6bd668ca3 --- /dev/null +++ b/queue-5.10/iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch @@ -0,0 +1,41 @@ +From 421a26f3d7a7c3ca43f3a9dc0f3cb0f562d5bd95 Mon Sep 17 00:00:00 2001 +From: Oliver Lang +Date: Thu, 10 Jun 2021 15:46:17 +0200 +Subject: iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTR + +From: Oliver Lang + +commit 421a26f3d7a7c3ca43f3a9dc0f3cb0f562d5bd95 upstream. + +The ltr559 chip uses only the lowest bit of the ALS_CONTR register to +configure between active and stand-by mode. In the original driver +BIT(1) is used, which does a software reset instead. + +This patch fixes the problem by using BIT(0) as als_mode_active for +the ltr559 chip. + +Fixes: 8592a7eefa54 ("iio: ltr501: Add support for ltr559 chip") +Signed-off-by: Oliver Lang +Reviewed-by: Andy Shevchenko +Signed-off-by: Marc Kleine-Budde +Tested-by: Nikita Travkin # ltr559 +Link: https://lore.kernel.org/r/20210610134619.2101372-3-mkl@pengutronix.de +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/light/ltr501.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/light/ltr501.c ++++ b/drivers/iio/light/ltr501.c +@@ -1208,7 +1208,7 @@ static struct ltr501_chip_info ltr501_ch + .als_gain_tbl_size = ARRAY_SIZE(ltr559_als_gain_tbl), + .ps_gain = ltr559_ps_gain_tbl, + .ps_gain_tbl_size = ARRAY_SIZE(ltr559_ps_gain_tbl), +- .als_mode_active = BIT(1), ++ .als_mode_active = BIT(0), + .als_gain_mask = BIT(2) | BIT(3) | BIT(4), + .als_gain_shift = 2, + .info = <r501_info, diff --git a/queue-5.10/iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch b/queue-5.10/iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch new file mode 100644 index 00000000000..d7039027b7a --- /dev/null +++ b/queue-5.10/iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch @@ -0,0 +1,68 @@ +From 2ac0b029a04b673ce83b5089368f467c5dca720c Mon Sep 17 00:00:00 2001 +From: Marc Kleine-Budde +Date: Thu, 10 Jun 2021 15:46:16 +0200 +Subject: iio: ltr501: mark register holding upper 8 bits of ALS_DATA{0,1} and PS_DATA as volatile, too + +From: Marc Kleine-Budde + +commit 2ac0b029a04b673ce83b5089368f467c5dca720c upstream. + +The regmap is configured for 8 bit registers, uses a RB-Tree cache and +marks several registers as volatile (i.e. do not cache). + +The ALS and PS data registers in the chip are 16 bit wide and spans +two regmap registers. In the current driver only the base register is +marked as volatile, resulting in the upper register only read once. + +Further the data sheet notes: + +| When the I2C read operation starts, all four ALS data registers are +| locked until the I2C read operation of register 0x8B is completed. + +Which results in the registers never update after the 2nd read. + +This patch fixes the problem by marking the upper 8 bits of the ALS +and PS registers as volatile, too. + +Fixes: 2f2c96338afc ("iio: ltr501: Add regmap support.") +Reported-by: Oliver Lang +Reviewed-by: Andy Shevchenko +Signed-off-by: Marc Kleine-Budde +Tested-by: Nikita Travkin # ltr559 +Link: https://lore.kernel.org/r/20210610134619.2101372-2-mkl@pengutronix.de +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/light/ltr501.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/iio/light/ltr501.c ++++ b/drivers/iio/light/ltr501.c +@@ -32,9 +32,12 @@ + #define LTR501_PART_ID 0x86 + #define LTR501_MANUFAC_ID 0x87 + #define LTR501_ALS_DATA1 0x88 /* 16-bit, little endian */ ++#define LTR501_ALS_DATA1_UPPER 0x89 /* upper 8 bits of LTR501_ALS_DATA1 */ + #define LTR501_ALS_DATA0 0x8a /* 16-bit, little endian */ ++#define LTR501_ALS_DATA0_UPPER 0x8b /* upper 8 bits of LTR501_ALS_DATA0 */ + #define LTR501_ALS_PS_STATUS 0x8c + #define LTR501_PS_DATA 0x8d /* 16-bit, little endian */ ++#define LTR501_PS_DATA_UPPER 0x8e /* upper 8 bits of LTR501_PS_DATA */ + #define LTR501_INTR 0x8f /* output mode, polarity, mode */ + #define LTR501_PS_THRESH_UP 0x90 /* 11 bit, ps upper threshold */ + #define LTR501_PS_THRESH_LOW 0x92 /* 11 bit, ps lower threshold */ +@@ -1354,9 +1357,12 @@ static bool ltr501_is_volatile_reg(struc + { + switch (reg) { + case LTR501_ALS_DATA1: ++ case LTR501_ALS_DATA1_UPPER: + case LTR501_ALS_DATA0: ++ case LTR501_ALS_DATA0_UPPER: + case LTR501_ALS_PS_STATUS: + case LTR501_PS_DATA: ++ case LTR501_PS_DATA_UPPER: + return true; + default: + return false; diff --git a/queue-5.10/kvm-nvmx-handle-split-lock-ac-exceptions-that-happen-in-l2.patch b/queue-5.10/kvm-nvmx-handle-split-lock-ac-exceptions-that-happen-in-l2.patch new file mode 100644 index 00000000000..4e40e72fcd3 --- /dev/null +++ b/queue-5.10/kvm-nvmx-handle-split-lock-ac-exceptions-that-happen-in-l2.patch @@ -0,0 +1,85 @@ +From b33bb78a1fada6445c265c585ee0dd0fc6279102 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 22 Jun 2021 10:22:44 -0700 +Subject: KVM: nVMX: Handle split-lock #AC exceptions that happen in L2 + +From: Sean Christopherson + +commit b33bb78a1fada6445c265c585ee0dd0fc6279102 upstream. + +Mark #ACs that won't be reinjected to the guest as wanted by L0 so that +KVM handles split-lock #AC from L2 instead of forwarding the exception to +L1. Split-lock #AC isn't yet virtualized, i.e. L1 will treat it like a +regular #AC and do the wrong thing, e.g. reinject it into L2. + +Fixes: e6f8b6c12f03 ("KVM: VMX: Extend VMXs #AC interceptor to handle split lock #AC in guest") +Cc: Xiaoyao Li +Signed-off-by: Sean Christopherson +Message-Id: <20210622172244.3561540-1-seanjc@google.com> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx/nested.c | 3 +++ + arch/x86/kvm/vmx/vmcs.h | 5 +++++ + arch/x86/kvm/vmx/vmx.c | 4 ++-- + arch/x86/kvm/vmx/vmx.h | 1 + + 4 files changed, 11 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/vmx/nested.c ++++ b/arch/x86/kvm/vmx/nested.c +@@ -5787,6 +5787,9 @@ static bool nested_vmx_l0_wants_exit(str + else if (is_breakpoint(intr_info) && + vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP) + return true; ++ else if (is_alignment_check(intr_info) && ++ !vmx_guest_inject_ac(vcpu)) ++ return true; + return false; + case EXIT_REASON_EXTERNAL_INTERRUPT: + return true; +--- a/arch/x86/kvm/vmx/vmcs.h ++++ b/arch/x86/kvm/vmx/vmcs.h +@@ -117,6 +117,11 @@ static inline bool is_gp_fault(u32 intr_ + return is_exception_n(intr_info, GP_VECTOR); + } + ++static inline bool is_alignment_check(u32 intr_info) ++{ ++ return is_exception_n(intr_info, AC_VECTOR); ++} ++ + static inline bool is_machine_check(u32 intr_info) + { + return is_exception_n(intr_info, MC_VECTOR); +--- a/arch/x86/kvm/vmx/vmx.c ++++ b/arch/x86/kvm/vmx/vmx.c +@@ -4755,7 +4755,7 @@ static int handle_machine_check(struct k + * - Guest has #AC detection enabled in CR0 + * - Guest EFLAGS has AC bit set + */ +-static inline bool guest_inject_ac(struct kvm_vcpu *vcpu) ++bool vmx_guest_inject_ac(struct kvm_vcpu *vcpu) + { + if (!boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT)) + return true; +@@ -4864,7 +4864,7 @@ static int handle_exception_nmi(struct k + kvm_run->debug.arch.exception = ex_no; + break; + case AC_VECTOR: +- if (guest_inject_ac(vcpu)) { ++ if (vmx_guest_inject_ac(vcpu)) { + kvm_queue_exception_e(vcpu, AC_VECTOR, error_code); + return 1; + } +--- a/arch/x86/kvm/vmx/vmx.h ++++ b/arch/x86/kvm/vmx/vmx.h +@@ -352,6 +352,7 @@ void vmx_set_segment(struct kvm_vcpu *vc + u64 construct_eptp(struct kvm_vcpu *vcpu, unsigned long root_hpa, + int root_level); + ++bool vmx_guest_inject_ac(struct kvm_vcpu *vcpu); + void update_exception_bitmap(struct kvm_vcpu *vcpu); + void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu); + bool vmx_nmi_blocked(struct kvm_vcpu *vcpu); diff --git a/queue-5.10/kvm-ppc-book3s-hv-workaround-high-stack-usage-with-clang.patch b/queue-5.10/kvm-ppc-book3s-hv-workaround-high-stack-usage-with-clang.patch new file mode 100644 index 00000000000..904a93f5858 --- /dev/null +++ b/queue-5.10/kvm-ppc-book3s-hv-workaround-high-stack-usage-with-clang.patch @@ -0,0 +1,57 @@ +From 51696f39cbee5bb684e7959c0c98b5f54548aa34 Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Mon, 21 Jun 2021 11:24:40 -0700 +Subject: KVM: PPC: Book3S HV: Workaround high stack usage with clang + +From: Nathan Chancellor + +commit 51696f39cbee5bb684e7959c0c98b5f54548aa34 upstream. + +LLVM does not emit optimal byteswap assembly, which results in high +stack usage in kvmhv_enter_nested_guest() due to the inlining of +byteswap_pt_regs(). With LLVM 12.0.0: + +arch/powerpc/kvm/book3s_hv_nested.c:289:6: error: stack frame size of +2512 bytes in function 'kvmhv_enter_nested_guest' [-Werror,-Wframe-larger-than=] +long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu) + ^ +1 error generated. + +While this gets fixed in LLVM, mark byteswap_pt_regs() as +noinline_for_stack so that it does not get inlined and break the build +due to -Werror by default in arch/powerpc/. Not inlining saves +approximately 800 bytes with LLVM 12.0.0: + +arch/powerpc/kvm/book3s_hv_nested.c:290:6: warning: stack frame size of +1728 bytes in function 'kvmhv_enter_nested_guest' [-Wframe-larger-than=] +long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu) + ^ +1 warning generated. + +Cc: stable@vger.kernel.org # v4.20+ +Reported-by: kernel test robot +Signed-off-by: Nathan Chancellor +Signed-off-by: Michael Ellerman +Link: https://github.com/ClangBuiltLinux/linux/issues/1292 +Link: https://bugs.llvm.org/show_bug.cgi?id=49610 +Link: https://lore.kernel.org/r/202104031853.vDT0Qjqj-lkp@intel.com/ +Link: https://gist.github.com/ba710e3703bf45043a31e2806c843ffd +Link: https://lore.kernel.org/r/20210621182440.990242-1-nathan@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kvm/book3s_hv_nested.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/kvm/book3s_hv_nested.c ++++ b/arch/powerpc/kvm/book3s_hv_nested.c +@@ -51,7 +51,8 @@ void kvmhv_save_hv_regs(struct kvm_vcpu + hr->ppr = vcpu->arch.ppr; + } + +-static void byteswap_pt_regs(struct pt_regs *regs) ++/* Use noinline_for_stack due to https://bugs.llvm.org/show_bug.cgi?id=49610 */ ++static noinline_for_stack void byteswap_pt_regs(struct pt_regs *regs) + { + unsigned long *addr = (unsigned long *) regs; + diff --git a/queue-5.10/kvm-x86-mmu-treat-nx-as-used-not-reserved-for-all-tdp-shadow-mmus.patch b/queue-5.10/kvm-x86-mmu-treat-nx-as-used-not-reserved-for-all-tdp-shadow-mmus.patch new file mode 100644 index 00000000000..d6160534582 --- /dev/null +++ b/queue-5.10/kvm-x86-mmu-treat-nx-as-used-not-reserved-for-all-tdp-shadow-mmus.patch @@ -0,0 +1,48 @@ +From 112022bdb5bc372e00e6e43cb88ee38ea67b97bd Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 22 Jun 2021 10:56:47 -0700 +Subject: KVM: x86/mmu: Treat NX as used (not reserved) for all !TDP shadow MMUs + +From: Sean Christopherson + +commit 112022bdb5bc372e00e6e43cb88ee38ea67b97bd upstream. + +Mark NX as being used for all non-nested shadow MMUs, as KVM will set the +NX bit for huge SPTEs if the iTLB mutli-hit mitigation is enabled. +Checking the mitigation itself is not sufficient as it can be toggled on +at any time and KVM doesn't reset MMU contexts when that happens. KVM +could reset the contexts, but that would require purging all SPTEs in all +MMUs, for no real benefit. And, KVM already forces EFER.NX=1 when TDP is +disabled (for WP=0, SMEP=1, NX=0), so technically NX is never reserved +for shadow MMUs. + +Fixes: b8e8c8303ff2 ("kvm: mmu: ITLB_MULTIHIT mitigation") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-Id: <20210622175739.3610207-3-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/mmu/mmu.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/mmu/mmu.c ++++ b/arch/x86/kvm/mmu/mmu.c +@@ -4133,7 +4133,15 @@ static void reset_rsvds_bits_mask_ept(st + void + reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context) + { +- bool uses_nx = context->nx || ++ /* ++ * KVM uses NX when TDP is disabled to handle a variety of scenarios, ++ * notably for huge SPTEs if iTLB multi-hit mitigation is enabled and ++ * to generate correct permissions for CR0.WP=0/CR4.SMEP=1/EFER.NX=0. ++ * The iTLB multi-hit workaround can be toggled at any time, so assume ++ * NX can be used by any non-nested shadow MMU to avoid having to reset ++ * MMU contexts. Note, KVM forces EFER.NX=1 when TDP is disabled. ++ */ ++ bool uses_nx = context->nx || !tdp_enabled || + context->mmu_role.base.smep_andnot_wp; + struct rsvd_bits_validate *shadow_zero_check; + int i; diff --git a/queue-5.10/kvm-x86-mmu-use-mmu-s-role-to-detect-cr4.smep-value-in-nested-npt-walk.patch b/queue-5.10/kvm-x86-mmu-use-mmu-s-role-to-detect-cr4.smep-value-in-nested-npt-walk.patch new file mode 100644 index 00000000000..21c4fc75e5f --- /dev/null +++ b/queue-5.10/kvm-x86-mmu-use-mmu-s-role-to-detect-cr4.smep-value-in-nested-npt-walk.patch @@ -0,0 +1,39 @@ +From ef318b9edf66a082f23d00d79b70c17b4c055a26 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 22 Jun 2021 10:56:49 -0700 +Subject: KVM: x86/mmu: Use MMU's role to detect CR4.SMEP value in nested NPT walk + +From: Sean Christopherson + +commit ef318b9edf66a082f23d00d79b70c17b4c055a26 upstream. + +Use the MMU's role to get its effective SMEP value when injecting a fault +into the guest. When walking L1's (nested) NPT while L2 is active, vCPU +state will reflect L2, whereas NPT uses the host's (L1 in this case) CR0, +CR4, EFER, etc... If L1 and L2 have different settings for SMEP and +L1 does not have EFER.NX=1, this can result in an incorrect PFEC.FETCH +when injecting #NPF. + +Fixes: e57d4a356ad3 ("KVM: Add instruction fetch checking when walking guest page table") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-Id: <20210622175739.3610207-5-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/mmu/paging_tmpl.h | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/arch/x86/kvm/mmu/paging_tmpl.h ++++ b/arch/x86/kvm/mmu/paging_tmpl.h +@@ -471,8 +471,7 @@ retry_walk: + + error: + errcode |= write_fault | user_fault; +- if (fetch_fault && (mmu->nx || +- kvm_read_cr4_bits(vcpu, X86_CR4_SMEP))) ++ if (fetch_fault && (mmu->nx || mmu->mmu_role.ext.cr4_smep)) + errcode |= PFERR_FETCH_MASK; + + walker->fault.vector = PF_VECTOR; diff --git a/queue-5.10/loop-fix-missing-discard-support-when-using-loop_configure.patch b/queue-5.10/loop-fix-missing-discard-support-when-using-loop_configure.patch new file mode 100644 index 00000000000..455c62614c9 --- /dev/null +++ b/queue-5.10/loop-fix-missing-discard-support-when-using-loop_configure.patch @@ -0,0 +1,36 @@ +From 2b9ac22b12a266eb4fec246a07b504dd4983b16b Mon Sep 17 00:00:00 2001 +From: Kristian Klausen +Date: Fri, 18 Jun 2021 13:51:57 +0200 +Subject: loop: Fix missing discard support when using LOOP_CONFIGURE + +From: Kristian Klausen + +commit 2b9ac22b12a266eb4fec246a07b504dd4983b16b upstream. + +Without calling loop_config_discard() the discard flag and parameters +aren't set/updated for the loop device and worst-case they could +indicate discard support when it isn't the case (ex: if the +LOOP_SET_STATUS ioctl was used with a different file prior to +LOOP_CONFIGURE). + +Cc: # 5.8.x- +Fixes: 3448914e8cc5 ("loop: Add LOOP_CONFIGURE ioctl") +Signed-off-by: Kristian Klausen +Link: https://lore.kernel.org/r/20210618115157.31452-1-kristian@klausen.dk +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/block/loop.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/block/loop.c ++++ b/drivers/block/loop.c +@@ -1161,6 +1161,7 @@ static int loop_configure(struct loop_de + blk_queue_physical_block_size(lo->lo_queue, bsize); + blk_queue_io_min(lo->lo_queue, bsize); + ++ loop_config_discard(lo); + loop_update_rotational(lo); + loop_update_dio(lo); + loop_sysfs_init(lo); diff --git a/queue-5.10/mac80211-remove-iwlwifi-specific-workaround-that-broke-sta-ndp-tx.patch b/queue-5.10/mac80211-remove-iwlwifi-specific-workaround-that-broke-sta-ndp-tx.patch new file mode 100644 index 00000000000..296c6846a10 --- /dev/null +++ b/queue-5.10/mac80211-remove-iwlwifi-specific-workaround-that-broke-sta-ndp-tx.patch @@ -0,0 +1,62 @@ +From e41eb3e408de27982a5f8f50b2dd8002bed96908 Mon Sep 17 00:00:00 2001 +From: Felix Fietkau +Date: Sat, 19 Jun 2021 12:15:17 +0200 +Subject: mac80211: remove iwlwifi specific workaround that broke sta NDP tx + +From: Felix Fietkau + +commit e41eb3e408de27982a5f8f50b2dd8002bed96908 upstream. + +Sending nulldata packets is important for sw AP link probing and detecting +4-address mode links. The checks that dropped these packets were apparently +added to work around an iwlwifi firmware bug with multi-TID aggregation. + +Fixes: 41cbb0f5a295 ("mac80211: add support for HE") +Cc: stable@vger.kernel.org +Signed-off-by: Felix Fietkau +Link: https://lore.kernel.org/r/20210619101517.90806-1-nbd@nbd.name +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 3 +++ + net/mac80211/mlme.c | 9 --------- + 2 files changed, 3 insertions(+), 9 deletions(-) + +--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c +@@ -1085,6 +1085,9 @@ static int iwl_mvm_tx_mpdu(struct iwl_mv + if (WARN_ON_ONCE(mvmsta->sta_id == IWL_MVM_INVALID_STA)) + return -1; + ++ if (unlikely(ieee80211_is_any_nullfunc(fc)) && sta->he_cap.has_he) ++ return -1; ++ + if (unlikely(ieee80211_is_probe_resp(fc))) + iwl_mvm_probe_resp_set_noa(mvm, skb); + +--- a/net/mac80211/mlme.c ++++ b/net/mac80211/mlme.c +@@ -1094,11 +1094,6 @@ void ieee80211_send_nullfunc(struct ieee + struct ieee80211_hdr_3addr *nullfunc; + struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; + +- /* Don't send NDPs when STA is connected HE */ +- if (sdata->vif.type == NL80211_IFTYPE_STATION && +- !(ifmgd->flags & IEEE80211_STA_DISABLE_HE)) +- return; +- + skb = ieee80211_nullfunc_get(&local->hw, &sdata->vif, + !ieee80211_hw_check(&local->hw, DOESNT_SUPPORT_QOS_NDP)); + if (!skb) +@@ -1130,10 +1125,6 @@ static void ieee80211_send_4addr_nullfun + if (WARN_ON(sdata->vif.type != NL80211_IFTYPE_STATION)) + return; + +- /* Don't send NDPs when connected HE */ +- if (!(sdata->u.mgd.flags & IEEE80211_STA_DISABLE_HE)) +- return; +- + skb = dev_alloc_skb(local->hw.extra_tx_headroom + 30); + if (!skb) + return; diff --git a/queue-5.10/mm-gup-fix-try_grab_compound_head-race-with-split_huge_page.patch b/queue-5.10/mm-gup-fix-try_grab_compound_head-race-with-split_huge_page.patch new file mode 100644 index 00000000000..57243200fae --- /dev/null +++ b/queue-5.10/mm-gup-fix-try_grab_compound_head-race-with-split_huge_page.patch @@ -0,0 +1,166 @@ +From c24d37322548a6ec3caec67100d28b9c1f89f60a Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Mon, 28 Jun 2021 19:33:23 -0700 +Subject: mm/gup: fix try_grab_compound_head() race with split_huge_page() + +From: Jann Horn + +commit c24d37322548a6ec3caec67100d28b9c1f89f60a upstream. + +try_grab_compound_head() is used to grab a reference to a page from +get_user_pages_fast(), which is only protected against concurrent freeing +of page tables (via local_irq_save()), but not against concurrent TLB +flushes, freeing of data pages, or splitting of compound pages. + +Because no reference is held to the page when try_grab_compound_head() is +called, the page may have been freed and reallocated by the time its +refcount has been elevated; therefore, once we're holding a stable +reference to the page, the caller re-checks whether the PTE still points +to the same page (with the same access rights). + +The problem is that try_grab_compound_head() has to grab a reference on +the head page; but between the time we look up what the head page is and +the time we actually grab a reference on the head page, the compound page +may have been split up (either explicitly through split_huge_page() or by +freeing the compound page to the buddy allocator and then allocating its +individual order-0 pages). If that happens, get_user_pages_fast() may end +up returning the right page but lifting the refcount on a now-unrelated +page, leading to use-after-free of pages. + +To fix it: Re-check whether the pages still belong together after lifting +the refcount on the head page. Move anything else that checks +compound_head(page) below the refcount increment. + +This can't actually happen on bare-metal x86 (because there, disabling +IRQs locks out remote TLB flushes), but it can happen on virtualized x86 +(e.g. under KVM) and probably also on arm64. The race window is pretty +narrow, and constantly allocating and shattering hugepages isn't exactly +fast; for now I've only managed to reproduce this in an x86 KVM guest with +an artificially widened timing window (by adding a loop that repeatedly +calls `inl(0x3f8 + 5)` in `try_get_compound_head()` to force VM exits, so +that PV TLB flushes are used instead of IPIs). + +As requested on the list, also replace the existing VM_BUG_ON_PAGE() with +a warning and bailout. Since the existing code only performed the BUG_ON +check on DEBUG_VM kernels, ensure that the new code also only performs the +check under that configuration - I don't want to mix two logically +separate changes together too much. The macro VM_WARN_ON_ONCE_PAGE() +doesn't return a value on !DEBUG_VM, so wrap the whole check in an #ifdef +block. An alternative would be to change the VM_WARN_ON_ONCE_PAGE() +definition for !DEBUG_VM such that it always returns false, but since that +would differ from the behavior of the normal WARN macros, it might be too +confusing for readers. + +Link: https://lkml.kernel.org/r/20210615012014.1100672-1-jannh@google.com +Fixes: 7aef4172c795 ("mm: handle PTE-mapped tail pages in gerneric fast gup implementaiton") +Signed-off-by: Jann Horn +Reviewed-by: John Hubbard +Cc: Matthew Wilcox +Cc: Kirill A. Shutemov +Cc: Jan Kara +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/gup.c | 58 +++++++++++++++++++++++++++++++++++++++++++--------------- + 1 file changed, 43 insertions(+), 15 deletions(-) + +--- a/mm/gup.c ++++ b/mm/gup.c +@@ -44,6 +44,23 @@ static void hpage_pincount_sub(struct pa + atomic_sub(refs, compound_pincount_ptr(page)); + } + ++/* Equivalent to calling put_page() @refs times. */ ++static void put_page_refs(struct page *page, int refs) ++{ ++#ifdef CONFIG_DEBUG_VM ++ if (VM_WARN_ON_ONCE_PAGE(page_ref_count(page) < refs, page)) ++ return; ++#endif ++ ++ /* ++ * Calling put_page() for each ref is unnecessarily slow. Only the last ++ * ref needs a put_page(). ++ */ ++ if (refs > 1) ++ page_ref_sub(page, refs - 1); ++ put_page(page); ++} ++ + /* + * Return the compound head page with ref appropriately incremented, + * or NULL if that failed. +@@ -56,6 +73,21 @@ static inline struct page *try_get_compo + return NULL; + if (unlikely(!page_cache_add_speculative(head, refs))) + return NULL; ++ ++ /* ++ * At this point we have a stable reference to the head page; but it ++ * could be that between the compound_head() lookup and the refcount ++ * increment, the compound page was split, in which case we'd end up ++ * holding a reference on a page that has nothing to do with the page ++ * we were given anymore. ++ * So now that the head page is stable, recheck that the pages still ++ * belong together. ++ */ ++ if (unlikely(compound_head(page) != head)) { ++ put_page_refs(head, refs); ++ return NULL; ++ } ++ + return head; + } + +@@ -96,6 +128,14 @@ static __maybe_unused struct page *try_g + return NULL; + + /* ++ * CAUTION: Don't use compound_head() on the page before this ++ * point, the result won't be stable. ++ */ ++ page = try_get_compound_head(page, refs); ++ if (!page) ++ return NULL; ++ ++ /* + * When pinning a compound page of order > 1 (which is what + * hpage_pincount_available() checks for), use an exact count to + * track it, via hpage_pincount_add/_sub(). +@@ -103,15 +143,10 @@ static __maybe_unused struct page *try_g + * However, be sure to *also* increment the normal page refcount + * field at least once, so that the page really is pinned. + */ +- if (!hpage_pincount_available(page)) +- refs *= GUP_PIN_COUNTING_BIAS; +- +- page = try_get_compound_head(page, refs); +- if (!page) +- return NULL; +- + if (hpage_pincount_available(page)) + hpage_pincount_add(page, refs); ++ else ++ page_ref_add(page, refs * (GUP_PIN_COUNTING_BIAS - 1)); + + mod_node_page_state(page_pgdat(page), NR_FOLL_PIN_ACQUIRED, + orig_refs); +@@ -135,14 +170,7 @@ static void put_compound_head(struct pag + refs *= GUP_PIN_COUNTING_BIAS; + } + +- VM_BUG_ON_PAGE(page_ref_count(page) < refs, page); +- /* +- * Calling put_page() for each ref is unnecessarily slow. Only the last +- * ref needs a put_page(). +- */ +- if (refs > 1) +- page_ref_sub(page, refs - 1); +- put_page(page); ++ put_page_refs(page, refs); + } + + /** diff --git a/queue-5.10/perf-smmuv3-don-t-trample-existing-events-with-global-filter.patch b/queue-5.10/perf-smmuv3-don-t-trample-existing-events-with-global-filter.patch new file mode 100644 index 00000000000..dac5e84316f --- /dev/null +++ b/queue-5.10/perf-smmuv3-don-t-trample-existing-events-with-global-filter.patch @@ -0,0 +1,64 @@ +From 4c1daba15c209b99d192f147fea3dade30f72ed2 Mon Sep 17 00:00:00 2001 +From: Robin Murphy +Date: Tue, 8 Jun 2021 12:55:12 +0100 +Subject: perf/smmuv3: Don't trample existing events with global filter + +From: Robin Murphy + +commit 4c1daba15c209b99d192f147fea3dade30f72ed2 upstream. + +With global filtering, we only allow an event to be scheduled if its +filter settings exactly match those of any existing events, therefore +it is pointless to reapply the filter in that case. Much worse, though, +is that in doing that we trample the event type of counter 0 if it's +already active, and never touch the appropriate PMEVTYPERn so the new +event is likely not counting the right thing either. Don't do that. + +CC: stable@vger.kernel.org +Signed-off-by: Robin Murphy +Link: https://lore.kernel.org/r/32c80c0e46237f49ad8da0c9f8864e13c4a803aa.1623153312.git.robin.murphy@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/perf/arm_smmuv3_pmu.c | 18 ++++++++++-------- + 1 file changed, 10 insertions(+), 8 deletions(-) + +--- a/drivers/perf/arm_smmuv3_pmu.c ++++ b/drivers/perf/arm_smmuv3_pmu.c +@@ -275,7 +275,7 @@ static int smmu_pmu_apply_event_filter(s + struct perf_event *event, int idx) + { + u32 span, sid; +- unsigned int num_ctrs = smmu_pmu->num_counters; ++ unsigned int cur_idx, num_ctrs = smmu_pmu->num_counters; + bool filter_en = !!get_filter_enable(event); + + span = filter_en ? get_filter_span(event) : +@@ -283,17 +283,19 @@ static int smmu_pmu_apply_event_filter(s + sid = filter_en ? get_filter_stream_id(event) : + SMMU_PMCG_DEFAULT_FILTER_SID; + +- /* Support individual filter settings */ +- if (!smmu_pmu->global_filter) { ++ cur_idx = find_first_bit(smmu_pmu->used_counters, num_ctrs); ++ /* ++ * Per-counter filtering, or scheduling the first globally-filtered ++ * event into an empty PMU so idx == 0 and it works out equivalent. ++ */ ++ if (!smmu_pmu->global_filter || cur_idx == num_ctrs) { + smmu_pmu_set_event_filter(event, idx, span, sid); + return 0; + } + +- /* Requested settings same as current global settings*/ +- idx = find_first_bit(smmu_pmu->used_counters, num_ctrs); +- if (idx == num_ctrs || +- smmu_pmu_check_global_filter(smmu_pmu->events[idx], event)) { +- smmu_pmu_set_event_filter(event, 0, span, sid); ++ /* Otherwise, must match whatever's currently scheduled */ ++ if (smmu_pmu_check_global_filter(smmu_pmu->events[cur_idx], event)) { ++ smmu_pmu_set_evtyper(smmu_pmu, idx, get_event(event)); + return 0; + } + diff --git a/queue-5.10/powerpc-stacktrace-fix-spurious-stale-traces-in-raise_backtrace_ipi.patch b/queue-5.10/powerpc-stacktrace-fix-spurious-stale-traces-in-raise_backtrace_ipi.patch new file mode 100644 index 00000000000..2ebb8ef2dc7 --- /dev/null +++ b/queue-5.10/powerpc-stacktrace-fix-spurious-stale-traces-in-raise_backtrace_ipi.patch @@ -0,0 +1,96 @@ +From 7c6986ade69e3c81bac831645bc72109cd798a80 Mon Sep 17 00:00:00 2001 +From: Michael Ellerman +Date: Fri, 25 Jun 2021 16:28:41 +1000 +Subject: powerpc/stacktrace: Fix spurious "stale" traces in raise_backtrace_ipi() + +From: Michael Ellerman + +commit 7c6986ade69e3c81bac831645bc72109cd798a80 upstream. + +In raise_backtrace_ipi() we iterate through the cpumask of CPUs, sending +each an IPI asking them to do a backtrace, but we don't wait for the +backtrace to happen. + +We then iterate through the CPU mask again, and if any CPU hasn't done +the backtrace and cleared itself from the mask, we print a trace on its +behalf, noting that the trace may be "stale". + +This works well enough when a CPU is not responding, because in that +case it doesn't receive the IPI and the sending CPU is left to print the +trace. But when all CPUs are responding we are left with a race between +the sending and receiving CPUs, if the sending CPU wins the race then it +will erroneously print a trace. + +This leads to spurious "stale" traces from the sending CPU, which can +then be interleaved messily with the receiving CPU, note the CPU +numbers, eg: + + [ 1658.929157][ C7] rcu: Stack dump where RCU GP kthread last ran: + [ 1658.929223][ C7] Sending NMI from CPU 7 to CPUs 1: + [ 1658.929303][ C1] NMI backtrace for cpu 1 + [ 1658.929303][ C7] CPU 1 didn't respond to backtrace IPI, inspecting paca. + [ 1658.929362][ C1] CPU: 1 PID: 325 Comm: kworker/1:1H Tainted: G W E 5.13.0-rc2+ #46 + [ 1658.929405][ C7] irq_soft_mask: 0x01 in_mce: 0 in_nmi: 0 current: 325 (kworker/1:1H) + [ 1658.929465][ C1] Workqueue: events_highpri test_work_fn [test_lockup] + [ 1658.929549][ C7] Back trace of paca->saved_r1 (0xc0000000057fb400) (possibly stale): + [ 1658.929592][ C1] NIP: c00000000002cf50 LR: c008000000820178 CTR: c00000000002cfa0 + +To fix it, change the logic so that the sending CPU waits 5s for the +receiving CPU to print its trace. If the receiving CPU prints its trace +successfully then the sending CPU just continues, avoiding any spurious +"stale" trace. + +This has the added benefit of allowing all CPUs to print their traces in +order and avoids any interleaving of their output. + +Fixes: 5cc05910f26e ("powerpc/64s: Wire up arch_trigger_cpumask_backtrace()") +Cc: stable@vger.kernel.org # v4.18+ +Reported-by: Nathan Lynch +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20210625140408.3351173-1-mpe@ellerman.id.au +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/stacktrace.c | 26 ++++++++++++++++++++------ + 1 file changed, 20 insertions(+), 6 deletions(-) + +--- a/arch/powerpc/kernel/stacktrace.c ++++ b/arch/powerpc/kernel/stacktrace.c +@@ -230,17 +230,31 @@ static void handle_backtrace_ipi(struct + + static void raise_backtrace_ipi(cpumask_t *mask) + { ++ struct paca_struct *p; + unsigned int cpu; ++ u64 delay_us; + + for_each_cpu(cpu, mask) { +- if (cpu == smp_processor_id()) ++ if (cpu == smp_processor_id()) { + handle_backtrace_ipi(NULL); +- else +- smp_send_safe_nmi_ipi(cpu, handle_backtrace_ipi, 5 * USEC_PER_SEC); +- } ++ continue; ++ } + +- for_each_cpu(cpu, mask) { +- struct paca_struct *p = paca_ptrs[cpu]; ++ delay_us = 5 * USEC_PER_SEC; ++ ++ if (smp_send_safe_nmi_ipi(cpu, handle_backtrace_ipi, delay_us)) { ++ // Now wait up to 5s for the other CPU to do its backtrace ++ while (cpumask_test_cpu(cpu, mask) && delay_us) { ++ udelay(1); ++ delay_us--; ++ } ++ ++ // Other CPU cleared itself from the mask ++ if (delay_us) ++ continue; ++ } ++ ++ p = paca_ptrs[cpu]; + + cpumask_clear_cpu(cpu, mask); + diff --git a/queue-5.10/rsi-assign-beacon-rate-settings-to-the-correct-rate_info-descriptor-field.patch b/queue-5.10/rsi-assign-beacon-rate-settings-to-the-correct-rate_info-descriptor-field.patch new file mode 100644 index 00000000000..9371054e6e9 --- /dev/null +++ b/queue-5.10/rsi-assign-beacon-rate-settings-to-the-correct-rate_info-descriptor-field.patch @@ -0,0 +1,51 @@ +From b1c3a24897bd528f2f4fda9fea7da08a84ae25b6 Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Fri, 7 May 2021 23:31:05 +0200 +Subject: rsi: Assign beacon rate settings to the correct rate_info descriptor field + +From: Marek Vasut + +commit b1c3a24897bd528f2f4fda9fea7da08a84ae25b6 upstream. + +The RSI_RATE_x bits must be assigned to struct rsi_data_desc rate_info +field. The rest of the driver does it correctly, except this one place, +so fix it. This is also aligned with the RSI downstream vendor driver. +Without this patch, an AP operating at 5 GHz does not transmit any +beacons at all, this patch fixes that. + +Fixes: d26a9559403c ("rsi: add beacon changes for AP mode") +Signed-off-by: Marek Vasut +Cc: Amitkumar Karwar +Cc: Angus Ainslie +Cc: David S. Miller +Cc: Jakub Kicinski +Cc: Kalle Valo +Cc: Karun Eagalapati +Cc: Martin Kepplinger +Cc: Prameela Rani Garnepudi +Cc: Sebastian Krzyszkowiak +Cc: Siva Rebbagondla +Cc: netdev@vger.kernel.org +Cc: stable@vger.kernel.org +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20210507213105.140138-1-marex@denx.de +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/rsi/rsi_91x_hal.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/wireless/rsi/rsi_91x_hal.c ++++ b/drivers/net/wireless/rsi/rsi_91x_hal.c +@@ -470,9 +470,9 @@ int rsi_prepare_beacon(struct rsi_common + } + + if (common->band == NL80211_BAND_2GHZ) +- bcn_frm->bbp_info |= cpu_to_le16(RSI_RATE_1); ++ bcn_frm->rate_info |= cpu_to_le16(RSI_RATE_1); + else +- bcn_frm->bbp_info |= cpu_to_le16(RSI_RATE_6); ++ bcn_frm->rate_info |= cpu_to_le16(RSI_RATE_6); + + if (mac_bcn->data[tim_offset + 2] == 0) + bcn_frm->frame_info |= cpu_to_le16(RSI_DATA_DESC_DTIM_BEACON); diff --git a/queue-5.10/rsi-fix-ap-mode-with-wpa-failure-due-to-encrypted-eapol.patch b/queue-5.10/rsi-fix-ap-mode-with-wpa-failure-due-to-encrypted-eapol.patch new file mode 100644 index 00000000000..97c7dd153a0 --- /dev/null +++ b/queue-5.10/rsi-fix-ap-mode-with-wpa-failure-due-to-encrypted-eapol.patch @@ -0,0 +1,115 @@ +From 314538041b5632ffaf64798faaeabaf2793fe029 Mon Sep 17 00:00:00 2001 +From: Martin Fuzzey +Date: Tue, 1 Jun 2021 18:19:53 +0200 +Subject: rsi: fix AP mode with WPA failure due to encrypted EAPOL + +From: Martin Fuzzey + +commit 314538041b5632ffaf64798faaeabaf2793fe029 upstream. + +In AP mode WPA2-PSK connections were not established. + +The reason was that the AP was sending the first message +of the 4 way handshake encrypted, even though no pairwise +key had (correctly) yet been set. + +Encryption was enabled if the "security_enable" driver flag +was set and encryption was not explicitly disabled by +IEEE80211_TX_INTFL_DONT_ENCRYPT. + +However security_enable was set when *any* key, including +the AP GTK key, had been set which was causing unwanted +encryption even if no key was avaialble for the unicast +packet to be sent. + +Fix this by adding a check that we have a key and drop +the old security_enable driver flag which is insufficient +and redundant. + +The Redpine downstream out of tree driver does it this way too. + +Regarding the Fixes tag the actual code being modified was +introduced earlier, with the original driver submission, in +dad0d04fa7ba ("rsi: Add RS9113 wireless driver"), however +at that time AP mode was not yet supported so there was +no bug at that point. + +So I have tagged the introduction of AP support instead +which was part of the patch set "rsi: support for AP mode" [1] + +It is not clear whether AP WPA has ever worked, I can see nothing +on the kernel side that broke it afterwards yet the AP support +patch series says "Tests are performed to confirm aggregation, +connections in WEP and WPA/WPA2 security." + +One possibility is that the initial tests were done with a modified +userspace (hostapd). + +[1] https://www.spinics.net/lists/linux-wireless/msg165302.html + +Signed-off-by: Martin Fuzzey +Fixes: 38ef62353acb ("rsi: security enhancements for AP mode") +CC: stable@vger.kernel.org +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/1622564459-24430-1-git-send-email-martin.fuzzey@flowbird.group +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/rsi/rsi_91x_hal.c | 2 +- + drivers/net/wireless/rsi/rsi_91x_mac80211.c | 3 --- + drivers/net/wireless/rsi/rsi_91x_mgmt.c | 3 +-- + drivers/net/wireless/rsi/rsi_main.h | 1 - + 4 files changed, 2 insertions(+), 7 deletions(-) + +--- a/drivers/net/wireless/rsi/rsi_91x_hal.c ++++ b/drivers/net/wireless/rsi/rsi_91x_hal.c +@@ -203,7 +203,7 @@ int rsi_prepare_data_desc(struct rsi_com + wh->frame_control |= cpu_to_le16(RSI_SET_PS_ENABLE); + + if ((!(info->flags & IEEE80211_TX_INTFL_DONT_ENCRYPT)) && +- (common->secinfo.security_enable)) { ++ info->control.hw_key) { + if (rsi_is_cipher_wep(common)) + ieee80211_size += 4; + else +--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c ++++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c +@@ -1028,7 +1028,6 @@ static int rsi_mac80211_set_key(struct i + mutex_lock(&common->mutex); + switch (cmd) { + case SET_KEY: +- secinfo->security_enable = true; + status = rsi_hal_key_config(hw, vif, key, sta); + if (status) { + mutex_unlock(&common->mutex); +@@ -1047,8 +1046,6 @@ static int rsi_mac80211_set_key(struct i + break; + + case DISABLE_KEY: +- if (vif->type == NL80211_IFTYPE_STATION) +- secinfo->security_enable = false; + rsi_dbg(ERR_ZONE, "%s: RSI del key\n", __func__); + memset(key, 0, sizeof(struct ieee80211_key_conf)); + status = rsi_hal_key_config(hw, vif, key, sta); +--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c ++++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c +@@ -1803,8 +1803,7 @@ int rsi_send_wowlan_request(struct rsi_c + RSI_WIFI_MGMT_Q); + cmd_frame->desc.desc_dword0.frame_type = WOWLAN_CONFIG_PARAMS; + cmd_frame->host_sleep_status = sleep_status; +- if (common->secinfo.security_enable && +- common->secinfo.gtk_cipher) ++ if (common->secinfo.gtk_cipher) + flags |= RSI_WOW_GTK_REKEY; + if (sleep_status) + cmd_frame->wow_flags = flags; +--- a/drivers/net/wireless/rsi/rsi_main.h ++++ b/drivers/net/wireless/rsi/rsi_main.h +@@ -151,7 +151,6 @@ enum edca_queue { + }; + + struct security_info { +- bool security_enable; + u32 ptk_cipher; + u32 gtk_cipher; + }; diff --git a/queue-5.10/rtc-stm32-fix-unbalanced-clk_disable_unprepare-on-probe-error-path.patch b/queue-5.10/rtc-stm32-fix-unbalanced-clk_disable_unprepare-on-probe-error-path.patch new file mode 100644 index 00000000000..d8303a914b0 --- /dev/null +++ b/queue-5.10/rtc-stm32-fix-unbalanced-clk_disable_unprepare-on-probe-error-path.patch @@ -0,0 +1,77 @@ +From 950ac33dbe6ff656a623d862022f0762ec061ba7 Mon Sep 17 00:00:00 2001 +From: Martin Fuzzey +Date: Mon, 7 Jun 2021 19:36:40 +0200 +Subject: rtc: stm32: Fix unbalanced clk_disable_unprepare() on probe error path + +From: Martin Fuzzey + +commit 950ac33dbe6ff656a623d862022f0762ec061ba7 upstream. + +The STM32MP1 RTC may have 2 clocks, the pclk and the rtc_ck. + +If clk_prepare_enable() fails for the second clock (rtc_ck) we must only +call clk_disable_unprepare() for the first clock (pclk) but currently we +call it on both leading to a WARN: + +[ 15.629568] WARNING: CPU: 0 PID: 146 at drivers/clk/clk.c:958 clk_core_disable+0xb0/0xc8 +[ 15.637620] ck_rtc already disabled +[ 15.663322] CPU: 0 PID: 146 Comm: systemd-udevd Not tainted 5.4.77-pknbsp-svn5759-atag-v5.4.77-204-gea4235203137-dirty #2413 +[ 15.674510] Hardware name: STM32 (Device Tree Support) +[ 15.679658] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) +[ 15.687371] [] (show_stack) from [] (dump_stack+0xc0/0xe0) +[ 15.694574] [] (dump_stack) from [] (__warn+0xc8/0xf0) +[ 15.701428] [] (__warn) from [] (warn_slowpath_fmt+0x60/0x94) +[ 15.708894] [] (warn_slowpath_fmt) from [] (clk_core_disable+0xb0/0xc8) +[ 15.717230] [] (clk_core_disable) from [] (clk_core_disable_lock+0x18/0x24) +[ 15.725924] [] (clk_core_disable_lock) from [] (stm32_rtc_probe+0x124/0x5e4 [rtc_stm32]) +[ 15.735739] [] (stm32_rtc_probe [rtc_stm32]) from [] (platform_drv_probe+0x48/0x98) +[ 15.745095] [] (platform_drv_probe) from [] (really_probe+0x1f0/0x458) +[ 15.753338] [] (really_probe) from [] (driver_probe_device+0x70/0x1c4) +[ 15.761584] [] (driver_probe_device) from [] (device_driver_attach+0x58/0x60) +[ 15.770439] [] (device_driver_attach) from [] (__driver_attach+0xcc/0x170) +[ 15.779032] [] (__driver_attach) from [] (bus_for_each_dev+0x58/0x7c) +[ 15.787191] [] (bus_for_each_dev) from [] (bus_add_driver+0xdc/0x1f8) +[ 15.795352] [] (bus_add_driver) from [] (driver_register+0x7c/0x110) +[ 15.803425] [] (driver_register) from [] (do_one_initcall+0x70/0x1b8) +[ 15.811588] [] (do_one_initcall) from [] (do_init_module+0x58/0x1f8) +[ 15.819660] [] (do_init_module) from [] (load_module+0x1e58/0x23c8) +[ 15.827646] [] (load_module) from [] (sys_finit_module+0xa0/0xd4) +[ 15.835459] [] (sys_finit_module) from [] (__sys_trace_return+0x0/0x20) + +Signed-off-by: Martin Fuzzey +Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver") +Cc: stable@vger.kernel.org +Reviewed-by: Nobuhiro Iwamatsu +Signed-off-by: Alexandre Belloni +Link: https://lore.kernel.org/r/1623087421-19722-1-git-send-email-martin.fuzzey@flowbird.group +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/rtc/rtc-stm32.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/rtc/rtc-stm32.c ++++ b/drivers/rtc/rtc-stm32.c +@@ -754,7 +754,7 @@ static int stm32_rtc_probe(struct platfo + + ret = clk_prepare_enable(rtc->rtc_ck); + if (ret) +- goto err; ++ goto err_no_rtc_ck; + + if (rtc->data->need_dbp) + regmap_update_bits(rtc->dbp, rtc->dbp_reg, +@@ -830,10 +830,12 @@ static int stm32_rtc_probe(struct platfo + } + + return 0; ++ + err: ++ clk_disable_unprepare(rtc->rtc_ck); ++err_no_rtc_ck: + if (rtc->data->has_pclk) + clk_disable_unprepare(rtc->pclk); +- clk_disable_unprepare(rtc->rtc_ck); + + if (rtc->data->need_dbp) + regmap_update_bits(rtc->dbp, rtc->dbp_reg, rtc->dbp_mask, 0); diff --git a/queue-5.10/s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch b/queue-5.10/s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch new file mode 100644 index 00000000000..834717c4cf9 --- /dev/null +++ b/queue-5.10/s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch @@ -0,0 +1,67 @@ +From c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 Mon Sep 17 00:00:00 2001 +From: Vineeth Vijayan +Date: Wed, 9 Jun 2021 09:21:08 +0200 +Subject: s390/cio: dont call css_wait_for_slow_path() inside a lock + +From: Vineeth Vijayan + +commit c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 upstream. + +Currently css_wait_for_slow_path() gets called inside the chp->lock. +The path-verification-loop of slowpath inside this lock could lead to +deadlock as reported by the lockdep validator. + +The ccw_device_get_chp_desc() during the instance of a device-set-online +would try to acquire the same 'chp->lock' to read the chp->desc. +The instance of this function can get called from multiple scenario, +like probing or setting-device online manually. This could, in some +corner-cases lead to the deadlock. + +lockdep validator reported this as, + + CPU0 CPU1 + ---- ---- + lock(&chp->lock); + lock(kn->active#43); + lock(&chp->lock); + lock((wq_completion)cio); + +The chp->lock was introduced to serialize the access of struct +channel_path. This lock is not needed for the css_wait_for_slow_path() +function, so invoke the slow-path function outside this lock. + +Fixes: b730f3a93395 ("[S390] cio: add lock to struct channel_path") +Cc: +Reviewed-by: Peter Oberparleiter +Signed-off-by: Vineeth Vijayan +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/s390/cio/chp.c | 3 +++ + drivers/s390/cio/chsc.c | 2 -- + 2 files changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/s390/cio/chp.c ++++ b/drivers/s390/cio/chp.c +@@ -255,6 +255,9 @@ static ssize_t chp_status_write(struct d + if (!num_args) + return count; + ++ /* Wait until previous actions have settled. */ ++ css_wait_for_slow_path(); ++ + if (!strncasecmp(cmd, "on", 2) || !strcmp(cmd, "1")) { + mutex_lock(&cp->lock); + error = s390_vary_chpid(cp->chpid, 1); +--- a/drivers/s390/cio/chsc.c ++++ b/drivers/s390/cio/chsc.c +@@ -757,8 +757,6 @@ int chsc_chp_vary(struct chp_id chpid, i + { + struct channel_path *chp = chpid_to_chp(chpid); + +- /* Wait until previous actions have settled. */ +- css_wait_for_slow_path(); + /* + * Redo PathVerification on the devices the chpid connects to + */ diff --git a/queue-5.10/s390-mm-fix-secure-storage-access-exception-handling.patch b/queue-5.10/s390-mm-fix-secure-storage-access-exception-handling.patch new file mode 100644 index 00000000000..45629a12a31 --- /dev/null +++ b/queue-5.10/s390-mm-fix-secure-storage-access-exception-handling.patch @@ -0,0 +1,134 @@ +From 85b18d7b5e7ffefb2f076186511d39c4990aa005 Mon Sep 17 00:00:00 2001 +From: Janosch Frank +Date: Tue, 12 Jan 2021 05:40:53 -0500 +Subject: s390: mm: Fix secure storage access exception handling + +From: Janosch Frank + +commit 85b18d7b5e7ffefb2f076186511d39c4990aa005 upstream. + +Turns out that the bit 61 in the TEID is not always 1 and if that's +the case the address space ID and the address are +unpredictable. Without an address and its address space ID we can't +export memory and hence we can only send a SIGSEGV to the process or +panic the kernel depending on who caused the exception. + +Unfortunately bit 61 is only reliable if we have the "misc" UV feature +bit. + +Signed-off-by: Janosch Frank +Reviewed-by: Christian Borntraeger +Fixes: 084ea4d611a3d ("s390/mm: add (non)secure page access exceptions handlers") +Cc: stable@vger.kernel.org +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/boot/uv.c | 1 + + arch/s390/include/asm/uv.h | 8 +++++++- + arch/s390/kernel/uv.c | 10 ++++++++++ + arch/s390/mm/fault.c | 26 ++++++++++++++++++++++++++ + 4 files changed, 44 insertions(+), 1 deletion(-) + +--- a/arch/s390/boot/uv.c ++++ b/arch/s390/boot/uv.c +@@ -36,6 +36,7 @@ void uv_query_info(void) + uv_info.max_sec_stor_addr = ALIGN(uvcb.max_guest_stor_addr, PAGE_SIZE); + uv_info.max_num_sec_conf = uvcb.max_num_sec_conf; + uv_info.max_guest_cpu_id = uvcb.max_guest_cpu_id; ++ uv_info.uv_feature_indications = uvcb.uv_feature_indications; + } + + #ifdef CONFIG_PROTECTED_VIRTUALIZATION_GUEST +--- a/arch/s390/include/asm/uv.h ++++ b/arch/s390/include/asm/uv.h +@@ -73,6 +73,10 @@ enum uv_cmds_inst { + BIT_UVC_CMD_UNPIN_PAGE_SHARED = 22, + }; + ++enum uv_feat_ind { ++ BIT_UV_FEAT_MISC = 0, ++}; ++ + struct uv_cb_header { + u16 len; + u16 cmd; /* Command Code */ +@@ -97,7 +101,8 @@ struct uv_cb_qui { + u64 max_guest_stor_addr; + u8 reserved88[158 - 136]; + u16 max_guest_cpu_id; +- u8 reserveda0[200 - 160]; ++ u64 uv_feature_indications; ++ u8 reserveda0[200 - 168]; + } __packed __aligned(8); + + /* Initialize Ultravisor */ +@@ -274,6 +279,7 @@ struct uv_info { + unsigned long max_sec_stor_addr; + unsigned int max_num_sec_conf; + unsigned short max_guest_cpu_id; ++ unsigned long uv_feature_indications; + }; + + extern struct uv_info uv_info; +--- a/arch/s390/kernel/uv.c ++++ b/arch/s390/kernel/uv.c +@@ -364,6 +364,15 @@ static ssize_t uv_query_facilities(struc + static struct kobj_attribute uv_query_facilities_attr = + __ATTR(facilities, 0444, uv_query_facilities, NULL); + ++static ssize_t uv_query_feature_indications(struct kobject *kobj, ++ struct kobj_attribute *attr, char *buf) ++{ ++ return sysfs_emit(buf, "%lx\n", uv_info.uv_feature_indications); ++} ++ ++static struct kobj_attribute uv_query_feature_indications_attr = ++ __ATTR(feature_indications, 0444, uv_query_feature_indications, NULL); ++ + static ssize_t uv_query_max_guest_cpus(struct kobject *kobj, + struct kobj_attribute *attr, char *page) + { +@@ -396,6 +405,7 @@ static struct kobj_attribute uv_query_ma + + static struct attribute *uv_query_attrs[] = { + &uv_query_facilities_attr.attr, ++ &uv_query_feature_indications_attr.attr, + &uv_query_max_guest_cpus_attr.attr, + &uv_query_max_guest_vms_attr.attr, + &uv_query_max_guest_addr_attr.attr, +--- a/arch/s390/mm/fault.c ++++ b/arch/s390/mm/fault.c +@@ -805,6 +805,32 @@ void do_secure_storage_access(struct pt_ + struct page *page; + int rc; + ++ /* ++ * bit 61 tells us if the address is valid, if it's not we ++ * have a major problem and should stop the kernel or send a ++ * SIGSEGV to the process. Unfortunately bit 61 is not ++ * reliable without the misc UV feature so we need to check ++ * for that as well. ++ */ ++ if (test_bit_inv(BIT_UV_FEAT_MISC, &uv_info.uv_feature_indications) && ++ !test_bit_inv(61, ®s->int_parm_long)) { ++ /* ++ * When this happens, userspace did something that it ++ * was not supposed to do, e.g. branching into secure ++ * memory. Trigger a segmentation fault. ++ */ ++ if (user_mode(regs)) { ++ send_sig(SIGSEGV, current, 0); ++ return; ++ } ++ ++ /* ++ * The kernel should never run into this case and we ++ * have no way out of this situation. ++ */ ++ panic("Unexpected PGM 0x3d with TEID bit 61=0"); ++ } ++ + switch (get_fault_type(regs)) { + case USER_FAULT: + mm = current->mm; diff --git a/queue-5.10/seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch b/queue-5.10/seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch new file mode 100644 index 00000000000..745760b450c --- /dev/null +++ b/queue-5.10/seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch @@ -0,0 +1,45 @@ +From 6a2cbc58d6c9d90cd74288cc497c2b45815bc064 Mon Sep 17 00:00:00 2001 +From: Yun Zhou +Date: Sat, 26 Jun 2021 11:21:56 +0800 +Subject: seq_buf: Make trace_seq_putmem_hex() support data longer than 8 + +From: Yun Zhou + +commit 6a2cbc58d6c9d90cd74288cc497c2b45815bc064 upstream. + +Since the raw memory 'data' does not go forward, it will dump repeated +data if the data length is more than 8. If we want to dump longer data +blocks, we need to repeatedly call macro SEQ_PUT_HEX_FIELD. I think it +is a bit redundant, and multiple function calls also affect the performance. + +Link: https://lore.kernel.org/lkml/20210625122453.5e2fe304@oasis.local.home/ +Link: https://lkml.kernel.org/r/20210626032156.47889-2-yun.zhou@windriver.com + +Cc: stable@vger.kernel.org +Fixes: 6d2289f3faa7 ("tracing: Make trace_seq_putmem_hex() more robust") +Signed-off-by: Yun Zhou +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + lib/seq_buf.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/lib/seq_buf.c ++++ b/lib/seq_buf.c +@@ -243,12 +243,14 @@ int seq_buf_putmem_hex(struct seq_buf *s + break; + + /* j increments twice per loop */ +- len -= j / 2; + hex[j++] = ' '; + + seq_buf_putmem(s, hex, j); + if (seq_buf_has_overflowed(s)) + return -1; ++ ++ len -= start_len; ++ data += start_len; + } + return 0; + } diff --git a/queue-5.10/serial-mvebu-uart-fix-calculation-of-clock-divisor.patch b/queue-5.10/serial-mvebu-uart-fix-calculation-of-clock-divisor.patch new file mode 100644 index 00000000000..17cde8a915a --- /dev/null +++ b/queue-5.10/serial-mvebu-uart-fix-calculation-of-clock-divisor.patch @@ -0,0 +1,35 @@ +From 9078204ca5c33ba20443a8623a41a68a9995a70d Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pali=20Roh=C3=A1r?= +Date: Fri, 25 Jun 2021 00:49:00 +0200 +Subject: serial: mvebu-uart: fix calculation of clock divisor +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Pali Rohár + +commit 9078204ca5c33ba20443a8623a41a68a9995a70d upstream. + +The clock divisor should be rounded to the closest value. + +Signed-off-by: Pali Rohár +Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate") +Cc: stable@vger.kernel.org # 0e4cf69ede87 ("serial: mvebu-uart: clarify the baud rate derivation") +Link: https://lore.kernel.org/r/20210624224909.6350-2-pali@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/mvebu-uart.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/tty/serial/mvebu-uart.c ++++ b/drivers/tty/serial/mvebu-uart.c +@@ -463,7 +463,7 @@ static int mvebu_uart_baud_rate_set(stru + * makes use of D to configure the desired baudrate. + */ + m_divisor = OSAMP_DEFAULT_DIVISOR; +- d_divisor = DIV_ROUND_UP(port->uartclk, baud * m_divisor); ++ d_divisor = DIV_ROUND_CLOSEST(port->uartclk, baud * m_divisor); + + brdv = readl(port->membase + UART_BRDV); + brdv &= ~BRDV_BAUD_MASK; diff --git a/queue-5.10/serial-sh-sci-stop-dmaengine-transfer-in-sci_stop_tx.patch b/queue-5.10/serial-sh-sci-stop-dmaengine-transfer-in-sci_stop_tx.patch new file mode 100644 index 00000000000..f604b9570fd --- /dev/null +++ b/queue-5.10/serial-sh-sci-stop-dmaengine-transfer-in-sci_stop_tx.patch @@ -0,0 +1,48 @@ +From 08a84410a04f05c7c1b8e833f552416d8eb9f6fe Mon Sep 17 00:00:00 2001 +From: Yoshihiro Shimoda +Date: Thu, 10 Jun 2021 20:08:06 +0900 +Subject: serial: sh-sci: Stop dmaengine transfer in sci_stop_tx() + +From: Yoshihiro Shimoda + +commit 08a84410a04f05c7c1b8e833f552416d8eb9f6fe upstream. + +Stop dmaengine transfer in sci_stop_tx(). Otherwise, the following +message is possible output when system enters suspend and while +transferring data, because clearing TIE bit in SCSCR is not able to +stop any dmaengine transfer. + + sh-sci e6550000.serial: ttySC1: Unable to drain transmitter + +Note that this driver has already used some #ifdef in the .c file +so that this patch also uses #ifdef to fix the issue. Otherwise, +build errors happens if the CONFIG_SERIAL_SH_SCI_DMA is disabled. + +Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.") +Cc: # v4.9+ +Signed-off-by: Yoshihiro Shimoda +Link: https://lore.kernel.org/r/20210610110806.277932-1-yoshihiro.shimoda.uh@renesas.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/sh-sci.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/tty/serial/sh-sci.c ++++ b/drivers/tty/serial/sh-sci.c +@@ -610,6 +610,14 @@ static void sci_stop_tx(struct uart_port + ctrl &= ~SCSCR_TIE; + + serial_port_out(port, SCSCR, ctrl); ++ ++#ifdef CONFIG_SERIAL_SH_SCI_DMA ++ if (to_sci_port(port)->chan_tx && ++ !dma_submit_error(to_sci_port(port)->cookie_tx)) { ++ dmaengine_terminate_async(to_sci_port(port)->chan_tx); ++ to_sci_port(port)->cookie_tx = -EINVAL; ++ } ++#endif + } + + static void sci_start_rx(struct uart_port *port) diff --git a/queue-5.10/serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch b/queue-5.10/serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch new file mode 100644 index 00000000000..5f1e5124bb8 --- /dev/null +++ b/queue-5.10/serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch @@ -0,0 +1,31 @@ +From d495dd743d5ecd47288156e25c4d9163294a0992 Mon Sep 17 00:00:00 2001 +From: Ondrej Zary +Date: Fri, 11 Jun 2021 22:19:40 +0200 +Subject: serial_cs: Add Option International GSM-Ready 56K/ISDN modem + +From: Ondrej Zary + +commit d495dd743d5ecd47288156e25c4d9163294a0992 upstream. + +Add support for Option International GSM-Ready 56K/ISDN PCMCIA modem +card. + +Signed-off-by: Ondrej Zary +Cc: stable +Link: https://lore.kernel.org/r/20210611201940.23898-2-linux@zary.sk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/8250/serial_cs.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/tty/serial/8250/serial_cs.c ++++ b/drivers/tty/serial/8250/serial_cs.c +@@ -780,6 +780,7 @@ static const struct pcmcia_device_id ser + PCMCIA_DEVICE_PROD_ID12("Multi-Tech", "MT2834LT", 0x5f73be51, 0x4cd7c09e), + PCMCIA_DEVICE_PROD_ID12("OEM ", "C288MX ", 0xb572d360, 0xd2385b7a), + PCMCIA_DEVICE_PROD_ID12("Option International", "V34bis GSM/PSTN Data/Fax Modem", 0x9d7cd6f5, 0x5cb8bf41), ++ PCMCIA_DEVICE_PROD_ID12("Option International", "GSM-Ready 56K/ISDN", 0x9d7cd6f5, 0xb23844aa), + PCMCIA_DEVICE_PROD_ID12("PCMCIA ", "C336MX ", 0x99bcafe9, 0xaa25bcab), + PCMCIA_DEVICE_PROD_ID12("Quatech Inc", "PCMCIA Dual RS-232 Serial Port Card", 0xc4420b35, 0x92abc92f), + PCMCIA_DEVICE_PROD_ID12("Quatech Inc", "Dual RS-232 Serial Port PC Card", 0xc4420b35, 0x031a380d), diff --git a/queue-5.10/serial_cs-remove-wrong-globetrotter.cis-entry.patch b/queue-5.10/serial_cs-remove-wrong-globetrotter.cis-entry.patch new file mode 100644 index 00000000000..7d4e76e838a --- /dev/null +++ b/queue-5.10/serial_cs-remove-wrong-globetrotter.cis-entry.patch @@ -0,0 +1,51 @@ +From 11b1d881a90fc184cc7d06e9804eb288c24a2a0d Mon Sep 17 00:00:00 2001 +From: Ondrej Zary +Date: Fri, 11 Jun 2021 22:19:39 +0200 +Subject: serial_cs: remove wrong GLOBETROTTER.cis entry + +From: Ondrej Zary + +commit 11b1d881a90fc184cc7d06e9804eb288c24a2a0d upstream. + +The GLOBETROTTER.cis entry in serial_cs matches more devices than +intended and breaks them. Remove it. + +Example: # pccardctl info +PRODID_1="Option International +" +PRODID_2="GSM-Ready 56K/ISDN +" +PRODID_3="021 +" +PRODID_4="A +" +MANFID=0013,0000 +FUNCID=0 + +result: +pcmcia 0.0: Direct firmware load for cis/GLOBETROTTER.cis failed with error -2 + +The GLOBETROTTER.cis is nowhere to be found. There's GLOBETROTTER.cis.ihex at +https://netdev.vger.kernel.narkive.com/h4inqdxM/patch-axnet-cs-fix-phy-id-detection-for-bogus-asix-chip#post41 +It's from completely diffetent card: +vers_1 4.1, "Option International", "GSM/GPRS GlobeTrotter", "001", "A" + +Signed-off-by: Ondrej Zary +Cc: stable +Link: https://lore.kernel.org/r/20210611201940.23898-1-linux@zary.sk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/8250/serial_cs.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/tty/serial/8250/serial_cs.c ++++ b/drivers/tty/serial/8250/serial_cs.c +@@ -808,7 +808,6 @@ static const struct pcmcia_device_id ser + PCMCIA_DEVICE_CIS_PROD_ID12("ADVANTECH", "COMpad-32/85B-4", 0x96913a85, 0xcec8f102, "cis/COMpad4.cis"), + PCMCIA_DEVICE_CIS_PROD_ID123("ADVANTECH", "COMpad-32/85", "1.0", 0x96913a85, 0x8fbe92ae, 0x0877b627, "cis/COMpad2.cis"), + PCMCIA_DEVICE_CIS_PROD_ID2("RS-COM 2P", 0xad20b156, "cis/RS-COM-2P.cis"), +- PCMCIA_DEVICE_CIS_MANF_CARD(0x0013, 0x0000, "cis/GLOBETROTTER.cis"), + PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.", "SERIAL CARD: SL100 1.00.", 0x19ca78af, 0xf964f42b), + PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.", "SERIAL CARD: SL100", 0x19ca78af, 0x71d98e83), + PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.", "SERIAL CARD: SL232 1.00.", 0x19ca78af, 0x69fb7490), diff --git a/queue-5.10/series b/queue-5.10/series index 53d92f9e188..366b1fe7f63 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -31,3 +31,68 @@ selftests-lkdtm-avoid-needing-explicit-sub-shell.patch copy_page_to_iter-fix-iter_discard-case.patch iov_iter_fault_in_readable-should-do-nothing-in-xarray-case.patch input-joydev-prevent-use-of-not-validated-data-in-jsiocsbtnmap-ioctl.patch +crypto-nx-fix-memcpy-over-reading-in-nonce.patch +crypto-ccp-annotate-sev-firmware-file-names.patch +arm_pmu-fix-write-counter-incorrect-in-armv7-big-endian-mode.patch +arm-dts-ux500-fix-led-probing.patch +arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch +btrfs-send-fix-invalid-path-for-unlink-operations-after-parent-orphanization.patch +btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch +btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch +ext4-cleanup-in-core-orphan-list-if-ext4_truncate-failed-to-get-a-transaction-handle.patch +ext4-fix-kernel-infoleak-via-ext4_extent_header.patch +ext4-fix-overflow-in-ext4_iomap_alloc.patch +ext4-return-error-code-when-ext4_fill_flex_info-fails.patch +ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch +ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch +ext4-fix-avefreec-in-find_group_orlov.patch +ext4-use-ext4_grp_locked_error-in-mb_find_extent.patch +can-bcm-delay-release-of-struct-bcm_op-after-synchronize_rcu.patch +can-gw-synchronize-rcu-operations-before-removing-gw-job-entry.patch +can-isotp-isotp_release-omit-unintended-hrtimer-restart-on-socket-release.patch +can-j1939-j1939_sk_init-set-sock_rcu_free-to-call-sk_destruct-after-rcu-is-done.patch +can-peak_pciefd-pucan_handle_status-fix-a-potential-starvation-issue-in-tx-path.patch +mac80211-remove-iwlwifi-specific-workaround-that-broke-sta-ndp-tx.patch +sunrpc-fix-the-batch-tasks-count-wraparound.patch +sunrpc-should-wake-up-the-privileged-task-firstly.patch +bus-mhi-wait-for-m2-state-during-system-resume.patch +mm-gup-fix-try_grab_compound_head-race-with-split_huge_page.patch +perf-smmuv3-don-t-trample-existing-events-with-global-filter.patch +kvm-nvmx-handle-split-lock-ac-exceptions-that-happen-in-l2.patch +kvm-ppc-book3s-hv-workaround-high-stack-usage-with-clang.patch +kvm-x86-mmu-treat-nx-as-used-not-reserved-for-all-tdp-shadow-mmus.patch +kvm-x86-mmu-use-mmu-s-role-to-detect-cr4.smep-value-in-nested-npt-walk.patch +s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch +s390-mm-fix-secure-storage-access-exception-handling.patch +f2fs-prevent-swap-file-in-lfs-mode.patch +clk-agilex-stratix10-n5x-fix-how-the-bypass_reg-is-handled.patch +clk-agilex-stratix10-remove-noc_clk.patch +clk-agilex-stratix10-fix-bypass-representation.patch +rtc-stm32-fix-unbalanced-clk_disable_unprepare-on-probe-error-path.patch +iio-frequency-adf4350-disable-reg-and-clk-on-error-in-adf4350_probe.patch +iio-light-tcs3472-do-not-free-unallocated-irq.patch +iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch +iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch +iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch +iio-accel-bma180-fix-bma25x-bandwidth-register-values.patch +serial-mvebu-uart-fix-calculation-of-clock-divisor.patch +serial-sh-sci-stop-dmaengine-transfer-in-sci_stop_tx.patch +serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch +serial_cs-remove-wrong-globetrotter.cis-entry.patch +ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch +ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch +rsi-assign-beacon-rate-settings-to-the-correct-rate_info-descriptor-field.patch +rsi-fix-ap-mode-with-wpa-failure-due-to-encrypted-eapol.patch +tracing-histograms-fix-parsing-of-sym-offset-modifier.patch +tracepoint-add-tracepoint_probe_register_may_exist-for-bpf-tracing.patch +seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch +powerpc-stacktrace-fix-spurious-stale-traces-in-raise_backtrace_ipi.patch +loop-fix-missing-discard-support-when-using-loop_configure.patch +evm-execute-evm_inode_init_security-only-when-an-hmac-key-is-loaded.patch +evm-refuse-evm_allow_metadata_writes-only-if-an-hmac-key-is-loaded.patch +fuse-fix-crash-in-fuse_dentry_automount-error-path.patch +fuse-fix-crash-if-superblock-of-submount-gets-killed-early.patch +fuse-fix-infinite-loop-in-sget_fc.patch +fuse-ignore-pg_workingset-after-stealing.patch +fuse-check-connected-before-queueing-on-fpq-io.patch +fuse-reject-internal-errno.patch diff --git a/queue-5.10/ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch b/queue-5.10/ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch new file mode 100644 index 00000000000..e0216010d8e --- /dev/null +++ b/queue-5.10/ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch @@ -0,0 +1,37 @@ +From 47ec636f7a25aa2549e198c48ecb6b1c25d05456 Mon Sep 17 00:00:00 2001 +From: Michael Buesch +Date: Sat, 15 May 2021 21:02:52 +0200 +Subject: ssb: sdio: Don't overwrite const buffer if block_write fails +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Michael Buesch + +commit 47ec636f7a25aa2549e198c48ecb6b1c25d05456 upstream. + +It doesn't make sense to clobber the const driver-side buffer, if a +write-to-device attempt failed. All other SSB variants (PCI, PCMCIA and SoC) +also don't corrupt the buffer on any failure in block_write. +Therefore, remove this memset from the SDIO variant. + +Signed-off-by: Michael Büsch +Cc: stable@vger.kernel.org +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20210515210252.318be2ba@wiggum +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ssb/sdio.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/ssb/sdio.c ++++ b/drivers/ssb/sdio.c +@@ -411,7 +411,6 @@ static void ssb_sdio_block_write(struct + sdio_claim_host(bus->host_sdio); + if (unlikely(ssb_sdio_switch_core(bus, dev))) { + error = -EIO; +- memset((void *)buffer, 0xff, count); + goto err_out; + } + offset |= bus->sdio_sbaddr & 0xffff; diff --git a/queue-5.10/sunrpc-fix-the-batch-tasks-count-wraparound.patch b/queue-5.10/sunrpc-fix-the-batch-tasks-count-wraparound.patch new file mode 100644 index 00000000000..fefc2491175 --- /dev/null +++ b/queue-5.10/sunrpc-fix-the-batch-tasks-count-wraparound.patch @@ -0,0 +1,48 @@ +From fcb170a9d825d7db4a3fb870b0300f5a40a8d096 Mon Sep 17 00:00:00 2001 +From: Zhang Xiaoxu +Date: Sat, 26 Jun 2021 15:50:41 +0800 +Subject: SUNRPC: Fix the batch tasks count wraparound. + +From: Zhang Xiaoxu + +commit fcb170a9d825d7db4a3fb870b0300f5a40a8d096 upstream. + +The 'queue->nr' will wraparound from 0 to 255 when only current +priority queue has tasks. This maybe lead a deadlock same as commit +dfe1fe75e00e ("NFSv4: Fix deadlock between nfs4_evict_inode() +and nfs4_opendata_get_inode()"): + +Privileged delegreturn task is queued to privileged list because all +the slots are assigned. When non-privileged task complete and release +the slot, a non-privileged maybe picked out. It maybe allocate slot +failed when the session on draining. + +If the 'queue->nr' has wraparound to 255, and no enough slot to +service it, then the privileged delegreturn will lost to wake up. + +So we should avoid the wraparound on 'queue->nr'. + +Reported-by: Hulk Robot +Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode") +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Cc: stable@vger.kernel.org +Signed-off-by: Zhang Xiaoxu +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman + +--- + net/sunrpc/sched.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/sunrpc/sched.c ++++ b/net/sunrpc/sched.c +@@ -595,7 +595,8 @@ static struct rpc_task *__rpc_find_next_ + * Service a batch of tasks from a single owner. + */ + q = &queue->tasks[queue->priority]; +- if (!list_empty(q) && --queue->nr) { ++ if (!list_empty(q) && queue->nr) { ++ queue->nr--; + task = list_first_entry(q, struct rpc_task, u.tk_wait.list); + goto out; + } diff --git a/queue-5.10/sunrpc-should-wake-up-the-privileged-task-firstly.patch b/queue-5.10/sunrpc-should-wake-up-the-privileged-task-firstly.patch new file mode 100644 index 00000000000..a22142f998d --- /dev/null +++ b/queue-5.10/sunrpc-should-wake-up-the-privileged-task-firstly.patch @@ -0,0 +1,52 @@ +From 5483b904bf336948826594610af4c9bbb0d9e3aa Mon Sep 17 00:00:00 2001 +From: Zhang Xiaoxu +Date: Sat, 26 Jun 2021 15:50:42 +0800 +Subject: SUNRPC: Should wake up the privileged task firstly. + +From: Zhang Xiaoxu + +commit 5483b904bf336948826594610af4c9bbb0d9e3aa upstream. + +When find a task from wait queue to wake up, a non-privileged task may +be found out, rather than the privileged. This maybe lead a deadlock +same as commit dfe1fe75e00e ("NFSv4: Fix deadlock between nfs4_evict_inode() +and nfs4_opendata_get_inode()"): + +Privileged delegreturn task is queued to privileged list because all +the slots are assigned. If there has no enough slot to wake up the +non-privileged batch tasks(session less than 8 slot), then the privileged +delegreturn task maybe lost waked up because the found out task can't +get slot since the session is on draining. + +So we should treate the privileged task as the emergency task, and +execute it as for as we can. + +Reported-by: Hulk Robot +Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode") +Cc: stable@vger.kernel.org +Signed-off-by: Zhang Xiaoxu +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman + +--- + net/sunrpc/sched.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/net/sunrpc/sched.c ++++ b/net/sunrpc/sched.c +@@ -592,6 +592,15 @@ static struct rpc_task *__rpc_find_next_ + struct rpc_task *task; + + /* ++ * Service the privileged queue. ++ */ ++ q = &queue->tasks[RPC_NR_PRIORITY - 1]; ++ if (queue->maxpriority > RPC_PRIORITY_PRIVILEGED && !list_empty(q)) { ++ task = list_first_entry(q, struct rpc_task, u.tk_wait.list); ++ goto out; ++ } ++ ++ /* + * Service a batch of tasks from a single owner. + */ + q = &queue->tasks[queue->priority]; diff --git a/queue-5.10/tracepoint-add-tracepoint_probe_register_may_exist-for-bpf-tracing.patch b/queue-5.10/tracepoint-add-tracepoint_probe_register_may_exist-for-bpf-tracing.patch new file mode 100644 index 00000000000..065eb592a93 --- /dev/null +++ b/queue-5.10/tracepoint-add-tracepoint_probe_register_may_exist-for-bpf-tracing.patch @@ -0,0 +1,143 @@ +From 9913d5745bd720c4266805c8d29952a3702e4eca Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (VMware)" +Date: Tue, 29 Jun 2021 09:40:10 -0400 +Subject: tracepoint: Add tracepoint_probe_register_may_exist() for BPF tracing + +From: Steven Rostedt (VMware) + +commit 9913d5745bd720c4266805c8d29952a3702e4eca upstream. + +All internal use cases for tracepoint_probe_register() is set to not ever +be called with the same function and data. If it is, it is considered a +bug, as that means the accounting of handling tracepoints is corrupted. +If the function and data for a tracepoint is already registered when +tracepoint_probe_register() is called, it will call WARN_ON_ONCE() and +return with EEXISTS. + +The BPF system call can end up calling tracepoint_probe_register() with +the same data, which now means that this can trigger the warning because +of a user space process. As WARN_ON_ONCE() should not be called because +user space called a system call with bad data, there needs to be a way to +register a tracepoint without triggering a warning. + +Enter tracepoint_probe_register_may_exist(), which can be called, but will +not cause a WARN_ON() if the probe already exists. It will still error out +with EEXIST, which will then be sent to the user space that performed the +BPF system call. + +This keeps the previous testing for issues with other users of the +tracepoint code, while letting BPF call it with duplicated data and not +warn about it. + +Link: https://lore.kernel.org/lkml/20210626135845.4080-1-penguin-kernel@I-love.SAKURA.ne.jp/ +Link: https://syzkaller.appspot.com/bug?id=41f4318cf01762389f4d1c1c459da4f542fe5153 + +Cc: stable@vger.kernel.org +Fixes: c4f6699dfcb85 ("bpf: introduce BPF_RAW_TRACEPOINT") +Reported-by: syzbot +Reported-by: Tetsuo Handa +Tested-by: syzbot+721aa903751db87aa244@syzkaller.appspotmail.com +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/tracepoint.h | 10 ++++++++++ + kernel/trace/bpf_trace.c | 3 ++- + kernel/tracepoint.c | 33 ++++++++++++++++++++++++++++++--- + 3 files changed, 42 insertions(+), 4 deletions(-) + +--- a/include/linux/tracepoint.h ++++ b/include/linux/tracepoint.h +@@ -41,7 +41,17 @@ extern int + tracepoint_probe_register_prio(struct tracepoint *tp, void *probe, void *data, + int prio); + extern int ++tracepoint_probe_register_prio_may_exist(struct tracepoint *tp, void *probe, void *data, ++ int prio); ++extern int + tracepoint_probe_unregister(struct tracepoint *tp, void *probe, void *data); ++static inline int ++tracepoint_probe_register_may_exist(struct tracepoint *tp, void *probe, ++ void *data) ++{ ++ return tracepoint_probe_register_prio_may_exist(tp, probe, data, ++ TRACEPOINT_DEFAULT_PRIO); ++} + extern void + for_each_kernel_tracepoint(void (*fct)(struct tracepoint *tp, void *priv), + void *priv); +--- a/kernel/trace/bpf_trace.c ++++ b/kernel/trace/bpf_trace.c +@@ -2106,7 +2106,8 @@ static int __bpf_probe_register(struct b + if (prog->aux->max_tp_access > btp->writable_size) + return -EINVAL; + +- return tracepoint_probe_register(tp, (void *)btp->bpf_func, prog); ++ return tracepoint_probe_register_may_exist(tp, (void *)btp->bpf_func, ++ prog); + } + + int bpf_probe_register(struct bpf_raw_event_map *btp, struct bpf_prog *prog) +--- a/kernel/tracepoint.c ++++ b/kernel/tracepoint.c +@@ -294,7 +294,8 @@ static void tracepoint_update_call(struc + * Add the probe function to a tracepoint. + */ + static int tracepoint_add_func(struct tracepoint *tp, +- struct tracepoint_func *func, int prio) ++ struct tracepoint_func *func, int prio, ++ bool warn) + { + struct tracepoint_func *old, *tp_funcs; + int ret; +@@ -309,7 +310,7 @@ static int tracepoint_add_func(struct tr + lockdep_is_held(&tracepoints_mutex)); + old = func_add(&tp_funcs, func, prio); + if (IS_ERR(old)) { +- WARN_ON_ONCE(PTR_ERR(old) != -ENOMEM); ++ WARN_ON_ONCE(warn && PTR_ERR(old) != -ENOMEM); + return PTR_ERR(old); + } + +@@ -365,6 +366,32 @@ static int tracepoint_remove_func(struct + } + + /** ++ * tracepoint_probe_register_prio_may_exist - Connect a probe to a tracepoint with priority ++ * @tp: tracepoint ++ * @probe: probe handler ++ * @data: tracepoint data ++ * @prio: priority of this function over other registered functions ++ * ++ * Same as tracepoint_probe_register_prio() except that it will not warn ++ * if the tracepoint is already registered. ++ */ ++int tracepoint_probe_register_prio_may_exist(struct tracepoint *tp, void *probe, ++ void *data, int prio) ++{ ++ struct tracepoint_func tp_func; ++ int ret; ++ ++ mutex_lock(&tracepoints_mutex); ++ tp_func.func = probe; ++ tp_func.data = data; ++ tp_func.prio = prio; ++ ret = tracepoint_add_func(tp, &tp_func, prio, false); ++ mutex_unlock(&tracepoints_mutex); ++ return ret; ++} ++EXPORT_SYMBOL_GPL(tracepoint_probe_register_prio_may_exist); ++ ++/** + * tracepoint_probe_register_prio - Connect a probe to a tracepoint with priority + * @tp: tracepoint + * @probe: probe handler +@@ -387,7 +414,7 @@ int tracepoint_probe_register_prio(struc + tp_func.func = probe; + tp_func.data = data; + tp_func.prio = prio; +- ret = tracepoint_add_func(tp, &tp_func, prio); ++ ret = tracepoint_add_func(tp, &tp_func, prio, true); + mutex_unlock(&tracepoints_mutex); + return ret; + } diff --git a/queue-5.10/tracing-histograms-fix-parsing-of-sym-offset-modifier.patch b/queue-5.10/tracing-histograms-fix-parsing-of-sym-offset-modifier.patch new file mode 100644 index 00000000000..595e9083e2b --- /dev/null +++ b/queue-5.10/tracing-histograms-fix-parsing-of-sym-offset-modifier.patch @@ -0,0 +1,52 @@ +From 26c563731056c3ee66f91106c3078a8c36bb7a9e Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (VMware)" +Date: Wed, 7 Jul 2021 11:08:21 -0400 +Subject: tracing/histograms: Fix parsing of "sym-offset" modifier + +From: Steven Rostedt (VMware) + +commit 26c563731056c3ee66f91106c3078a8c36bb7a9e upstream. + +With the addition of simple mathematical operations (plus and minus), the +parsing of the "sym-offset" modifier broke, as it took the '-' part of the +"sym-offset" as a minus, and tried to break it up into a mathematical +operation of "field.sym - offset", in which case it failed to parse +(unless the event had a field called "offset"). + +Both .sym and .sym-offset modifiers should not be entered into +mathematical calculations anyway. If ".sym-offset" is found in the +modifier, then simply make it not an operation that can be calculated on. + +Link: https://lkml.kernel.org/r/20210707110821.188ae255@oasis.local.home + +Cc: Ingo Molnar +Cc: Andrew Morton +Cc: Masami Hiramatsu +Cc: Namhyung Kim +Cc: Daniel Bristot de Oliveira +Cc: stable@vger.kernel.org +Fixes: 100719dcef447 ("tracing: Add simple expression support to hist triggers") +Reviewed-by: Tom Zanussi +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace_events_hist.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/kernel/trace/trace_events_hist.c ++++ b/kernel/trace/trace_events_hist.c +@@ -1539,6 +1539,13 @@ static int contains_operator(char *str) + + switch (*op) { + case '-': ++ /* ++ * Unfortunately, the modifier ".sym-offset" ++ * can confuse things. ++ */ ++ if (op - str >= 4 && !strncmp(op - 4, ".sym-offset", 11)) ++ return FIELD_OP_NONE; ++ + if (*str == '-') + field_op = FIELD_OP_UNARY_MINUS; + else