--- /dev/null
+From 253adffb0e98eaf6da2e7cf73ae68695e21f2f3c Mon Sep 17 00:00:00 2001
+From: Ludovic Desroches <ludovic.desroches@microchip.com>
+Date: Fri, 25 Oct 2019 10:42:10 +0200
+Subject: ARM: dts: at91: sama5d4: fix pinctrl muxing
+
+From: Ludovic Desroches <ludovic.desroches@microchip.com>
+
+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 <ludovic.desroches@microchip.com>
+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 <claudiu.beznea@microchip.com>
+Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
+Link: https://lore.kernel.org/r/20191025084210.14726-1-ludovic.desroches@microchip.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -787,7 +787,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 */
+ >;
+
--- /dev/null
+From 7749510c459c10c431d746a4749e7c9cf2899156 Mon Sep 17 00:00:00 2001
+From: Linus Walleij <linus.walleij@linaro.org>
+Date: Sun, 13 Jun 2021 14:33:56 +0200
+Subject: ARM: dts: ux500: Fix LED probing
+
+From: Linus Walleij <linus.walleij@linaro.org>
+
+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 <dmurphy@ti.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Olof Johansson <olof@lixom.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/ste-href.dtsi | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/arch/arm/boot/dts/ste-href.dtsi
++++ b/arch/arm/boot/dts/ste-href.dtsi
+@@ -4,6 +4,7 @@
+ */
+
+ #include <dt-bindings/interrupt-controller/irq.h>
++#include <dt-bindings/leds/common.h>
+ #include "ste-href-family-pinctrl.dtsi"
+
+ / {
+@@ -64,17 +65,20 @@
+ reg = <0>;
+ led-cur = /bits/ 8 <0x2f>;
+ max-cur = /bits/ 8 <0x5f>;
++ color = <LED_COLOR_ID_BLUE>;
+ linux,default-trigger = "heartbeat";
+ };
+ chan@1 {
+ reg = <1>;
+ led-cur = /bits/ 8 <0x2f>;
+ max-cur = /bits/ 8 <0x5f>;
++ color = <LED_COLOR_ID_BLUE>;
+ };
+ chan@2 {
+ reg = <2>;
+ led-cur = /bits/ 8 <0x2f>;
+ max-cur = /bits/ 8 <0x5f>;
++ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ lp5521@34 {
+@@ -88,16 +92,19 @@
+ reg = <0>;
+ led-cur = /bits/ 8 <0x2f>;
+ max-cur = /bits/ 8 <0x5f>;
++ color = <LED_COLOR_ID_BLUE>;
+ };
+ chan@1 {
+ reg = <1>;
+ led-cur = /bits/ 8 <0x2f>;
+ max-cur = /bits/ 8 <0x5f>;
++ color = <LED_COLOR_ID_BLUE>;
+ };
+ chan@2 {
+ reg = <2>;
+ led-cur = /bits/ 8 <0x2f>;
+ max-cur = /bits/ 8 <0x5f>;
++ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ bh1780@29 {
--- /dev/null
+From fdbef8c4e68ad423416aa6cc93d1616d6f8ac5b3 Mon Sep 17 00:00:00 2001
+From: Yang Jihong <yangjihong1@huawei.com>
+Date: Fri, 30 Apr 2021 09:26:59 +0800
+Subject: arm_pmu: Fix write counter incorrect in ARMv7 big-endian mode
+
+From: Yang Jihong <yangjihong1@huawei.com>
+
+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: <stable@vger.kernel.org>
+Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
+Acked-by: Mark Rutland <mark.rutland@arm.com>
+Link: https://lore.kernel.org/r/20210430012659.232110-1-yangjihong1@huawei.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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));
+ }
+ }
+
--- /dev/null
+From fb312ac5ccb007e843f982b38d4d6886ba4b32f2 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali@kernel.org>
+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 <pali@kernel.org>
+
+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 <pali@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20210402122653.24014-1-pali@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From 6819703f5a365c95488b07066a8744841bf14231 Mon Sep 17 00:00:00 2001
+From: David Sterba <dsterba@suse.com>
+Date: Tue, 7 Jul 2020 18:30:06 +0200
+Subject: btrfs: clear defrag status of a root if starting transaction fails
+
+From: David Sterba <dsterba@suse.com>
+
+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 <wqu@suse.com>
+Reviewed-by: Anand Jain <anand.jain@oracle.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/transaction.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/transaction.c
++++ b/fs/btrfs/transaction.c
+@@ -1393,8 +1393,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);
+
--- /dev/null
+From f2165627319ffd33a6217275e5690b1ab5c45763 Mon Sep 17 00:00:00 2001
+From: David Sterba <dsterba@suse.com>
+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 <dsterba@suse.com>
+
+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 <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/inode.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/inode.c
++++ b/fs/btrfs/inode.c
+@@ -598,7 +598,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) {
--- /dev/null
+From 44365827cccc1441d4187509257e5276af133a49 Mon Sep 17 00:00:00 2001
+From: Naohiro Aota <naohiro.aota@wdc.com>
+Date: Mon, 21 Jun 2021 10:21:14 +0900
+Subject: btrfs: fix unbalanced unlock in qgroup_account_snapshot()
+
+From: Naohiro Aota <naohiro.aota@wdc.com>
+
+commit 44365827cccc1441d4187509257e5276af133a49 upstream.
+
+qgroup_account_snapshot() is trying to unlock the not taken
+tree_log_mutex in a error path. Since ret != 0 in this case, we can
+just return from here.
+
+Fixes: 2a4d84c11a87 ("btrfs: move delayed ref flushing for qgroup into qgroup helper")
+CC: stable@vger.kernel.org # 5.12+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/transaction.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/transaction.c
++++ b/fs/btrfs/transaction.c
+@@ -1461,7 +1461,7 @@ static int qgroup_account_snapshot(struc
+ ret = btrfs_run_delayed_refs(trans, (unsigned long)-1);
+ if (ret) {
+ btrfs_abort_transaction(trans, ret);
+- goto out;
++ return ret;
+ }
+
+ /*
--- /dev/null
+From d8ac76cdd1755b21e8c008c28d0b7251c0b14986 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Wed, 9 Jun 2021 11:25:03 +0100
+Subject: btrfs: send: fix invalid path for unlink operations after parent orphanization
+
+From: Filipe Manana <fdmanana@suse.com>
+
+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 <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/send.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/fs/btrfs/send.c
++++ b/fs/btrfs/send.c
+@@ -4064,6 +4064,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;
--- /dev/null
+From 06e1e7f4223c98965fb721b4b1e12083cfbe777e Mon Sep 17 00:00:00 2001
+From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Date: Fri, 30 Apr 2021 15:34:18 +0200
+Subject: btrfs: zoned: bail out if we can't read a reliable write pointer
+
+From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+
+commit 06e1e7f4223c98965fb721b4b1e12083cfbe777e upstream.
+
+If we can't read a reliable write pointer from a sequential zone fail
+creating the block group with an I/O error.
+
+Also if the read write pointer is beyond the end of the respective zone,
+fail the creation of the block group on this zone with an I/O error.
+
+While this could also happen in real world scenarios with misbehaving
+drives, this issue addresses a problem uncovered by fstests' test case
+generic/475.
+
+CC: stable@vger.kernel.org # 5.12+
+Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/zoned.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/fs/btrfs/zoned.c
++++ b/fs/btrfs/zoned.c
+@@ -1204,6 +1204,13 @@ int btrfs_load_block_group_zone_info(str
+
+ switch (map->type & BTRFS_BLOCK_GROUP_PROFILE_MASK) {
+ case 0: /* single */
++ if (alloc_offsets[0] == WP_MISSING_DEV) {
++ btrfs_err(fs_info,
++ "zoned: cannot recover write pointer for zone %llu",
++ physical);
++ ret = -EIO;
++ goto out;
++ }
+ cache->alloc_offset = alloc_offsets[0];
+ break;
+ case BTRFS_BLOCK_GROUP_DUP:
+@@ -1221,6 +1228,13 @@ int btrfs_load_block_group_zone_info(str
+ }
+
+ out:
++ if (cache->alloc_offset > fs_info->zone_size) {
++ btrfs_err(fs_info,
++ "zoned: invalid write pointer %llu in block group %llu",
++ cache->alloc_offset, cache->start);
++ ret = -EIO;
++ }
++
+ /* An extent is allocated after the write pointer */
+ if (!ret && num_conventional && last_alloc > cache->alloc_offset) {
+ btrfs_err(fs_info,
--- /dev/null
+From 47cdfb5e1dd60422ec2cbc53b667f73ff9a411dc Mon Sep 17 00:00:00 2001
+From: Naohiro Aota <naohiro.aota@wdc.com>
+Date: Fri, 30 Apr 2021 15:34:17 +0200
+Subject: btrfs: zoned: print message when zone sanity check type fails
+
+From: Naohiro Aota <naohiro.aota@wdc.com>
+
+commit 47cdfb5e1dd60422ec2cbc53b667f73ff9a411dc upstream.
+
+This extends patch 784daf2b9628 ("btrfs: zoned: sanity check zone
+type"), the message was supposed to be there but was lost during merge.
+We want to make the error noticeable so add it.
+
+Fixes: 784daf2b9628 ("btrfs: zoned: sanity check zone type")
+CC: stable@vger.kernel.org # 5.12+
+Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/zoned.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/btrfs/zoned.c
++++ b/fs/btrfs/zoned.c
+@@ -1140,6 +1140,10 @@ int btrfs_load_block_group_zone_info(str
+ }
+
+ if (zone.type == BLK_ZONE_TYPE_CONVENTIONAL) {
++ btrfs_err_in_rcu(fs_info,
++ "zoned: unexpected conventional zone %llu on device %s (devid %llu)",
++ zone.start << SECTOR_SHIFT,
++ rcu_str_deref(device->name), device->devid);
+ ret = -EIO;
+ goto out;
+ }
--- /dev/null
+From 44b1eba44dc537edf076f131f1eeee7544d0e04f Mon Sep 17 00:00:00 2001
+From: Loic Poulain <loic.poulain@linaro.org>
+Date: Mon, 21 Jun 2021 21:46:10 +0530
+Subject: bus: mhi: core: Fix power down latency
+
+From: Loic Poulain <loic.poulain@linaro.org>
+
+commit 44b1eba44dc537edf076f131f1eeee7544d0e04f upstream.
+
+On graceful power-down/disable transition, when an MHI reset is
+performed, the MHI device loses its context, including interrupt
+configuration. However, the current implementation is waiting for
+event(irq) driven state change to confirm reset has been completed,
+which never happens, and causes reset timeout, leading to unexpected
+high latency of the mhi_power_down procedure (up to 45 seconds).
+
+Fix that by moving to the recently introduced poll_reg_field method,
+waiting for the reset bit to be cleared, in the same way as the
+power_on procedure.
+
+Cc: stable@vger.kernel.org
+Fixes: a6e2e3522f29 ("bus: mhi: core: Add support for PM state transitions")
+Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
+Reviewed-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
+Link: https://lore.kernel.org/r/1620029090-8975-1-git-send-email-loic.poulain@linaro.org
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Link: https://lore.kernel.org/r/20210621161616.77524-3-manivannan.sadhasivam@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bus/mhi/core/pm.c | 18 +++++-------------
+ 1 file changed, 5 insertions(+), 13 deletions(-)
+
+--- a/drivers/bus/mhi/core/pm.c
++++ b/drivers/bus/mhi/core/pm.c
+@@ -467,23 +467,15 @@ static void mhi_pm_disable_transition(st
+
+ /* Trigger MHI RESET so that the device will not access host memory */
+ if (!MHI_PM_IN_FATAL_STATE(mhi_cntrl->pm_state)) {
+- u32 in_reset = -1;
+- unsigned long timeout = msecs_to_jiffies(mhi_cntrl->timeout_ms);
+-
+ dev_dbg(dev, "Triggering MHI Reset in device\n");
+ mhi_set_mhi_state(mhi_cntrl, MHI_STATE_RESET);
+
+ /* Wait for the reset bit to be cleared by the device */
+- ret = wait_event_timeout(mhi_cntrl->state_event,
+- mhi_read_reg_field(mhi_cntrl,
+- mhi_cntrl->regs,
+- MHICTRL,
+- MHICTRL_RESET_MASK,
+- MHICTRL_RESET_SHIFT,
+- &in_reset) ||
+- !in_reset, timeout);
+- if (!ret || in_reset)
+- dev_err(dev, "Device failed to exit MHI Reset state\n");
++ ret = mhi_poll_reg_field(mhi_cntrl, mhi_cntrl->regs, MHICTRL,
++ MHICTRL_RESET_MASK, MHICTRL_RESET_SHIFT, 0,
++ 25000);
++ if (ret)
++ dev_err(dev, "Device failed to clear MHI Reset\n");
+
+ /*
+ * Device will clear BHI_INTVEC as a part of RESET processing,
--- /dev/null
+From a25d144fb883c73506ba384de476bbaff8220a95 Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Mon, 21 Jun 2021 21:46:13 +0530
+Subject: bus: mhi: pci-generic: Add missing 'pci_disable_pcie_error_reporting()' calls
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit a25d144fb883c73506ba384de476bbaff8220a95 upstream.
+
+If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
+must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
+call
+
+Add the missing call in the error handling path of the probe and in the
+remove function.
+
+Cc: <stable@vger.kernel.org>
+Fixes: b012ee6bfe2a ("mhi: pci_generic: Add PCI error handlers")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Link: https://lore.kernel.org/r/f70c14701f4922d67e717633c91b6c481b59f298.1623445348.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Link: https://lore.kernel.org/r/20210621161616.77524-6-manivannan.sadhasivam@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bus/mhi/pci_generic.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/bus/mhi/pci_generic.c
++++ b/drivers/bus/mhi/pci_generic.c
+@@ -470,7 +470,7 @@ static int mhi_pci_probe(struct pci_dev
+
+ err = mhi_register_controller(mhi_cntrl, mhi_cntrl_config);
+ if (err)
+- return err;
++ goto err_disable_reporting;
+
+ /* MHI bus does not power up the controller by default */
+ err = mhi_prepare_for_power_up(mhi_cntrl);
+@@ -496,6 +496,8 @@ err_unprepare:
+ mhi_unprepare_after_power_down(mhi_cntrl);
+ err_unregister:
+ mhi_unregister_controller(mhi_cntrl);
++err_disable_reporting:
++ pci_disable_pcie_error_reporting(pdev);
+
+ return err;
+ }
+@@ -514,6 +516,7 @@ static void mhi_pci_remove(struct pci_de
+ }
+
+ mhi_unregister_controller(mhi_cntrl);
++ pci_disable_pcie_error_reporting(pdev);
+ }
+
+ static void mhi_pci_shutdown(struct pci_dev *pdev)
--- /dev/null
+From 02b49cd1174527e611768fc2ce0f75a74dfec7ae Mon Sep 17 00:00:00 2001
+From: Baochen Qiang <bqiang@codeaurora.org>
+Date: Mon, 21 Jun 2021 21:46:11 +0530
+Subject: bus: mhi: Wait for M2 state during system resume
+
+From: Baochen Qiang <bqiang@codeaurora.org>
+
+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 <bqiang@codeaurora.org>
+Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Link: https://lore.kernel.org/r/20210524040312.14409-1-bqiang@codeaurora.org
+[mani: slightly massaged the commit message]
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Link: https://lore.kernel.org/r/20210621161616.77524-4-manivannan.sadhasivam@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -903,6 +903,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));
+
--- /dev/null
+From d5f9023fa61ee8b94f37a93f08e94b136cf1e463 Mon Sep 17 00:00:00 2001
+From: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+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 <cascardo@canonical.com>
+
+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 <stable@vger.kernel.org>
+Reported-by: syzbot+0f7e7e5e2f4f40fa89c0@syzkaller.appspotmail.com
+Reported-by: Norbert Slusarek <nslusarek@gmx.net>
+Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From fb8696ab14adadb2e3f6c17c18ed26b3ecd96691 Mon Sep 17 00:00:00 2001
+From: Oliver Hartkopp <socketcan@hartkopp.net>
+Date: Fri, 18 Jun 2021 19:36:45 +0200
+Subject: can: gw: synchronize rcu operations before removing gw job entry
+
+From: Oliver Hartkopp <socketcan@hartkopp.net>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/can/gw.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/can/gw.c
++++ b/net/can/gw.c
+@@ -596,6 +596,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);
+ }
+ }
+@@ -1154,6 +1155,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);
+ }
+ }
+@@ -1222,6 +1224,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;
--- /dev/null
+From 14a4696bc3118ba49da28f79280e1d55603aa737 Mon Sep 17 00:00:00 2001
+From: Oliver Hartkopp <socketcan@hartkopp.net>
+Date: Fri, 18 Jun 2021 19:37:13 +0200
+Subject: can: isotp: isotp_release(): omit unintended hrtimer restart on socket release
+
+From: Oliver Hartkopp <socketcan@hartkopp.net>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/can/isotp.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/net/can/isotp.c
++++ b/net/can/isotp.c
+@@ -1028,9 +1028,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 && (!(so->opt.flags & CAN_ISOTP_SF_BROADCAST))) {
+ if (so->ifindex) {
+@@ -1042,10 +1039,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;
+
--- /dev/null
+From 22c696fed25c63c7f67508309820358b94a96b6d Mon Sep 17 00:00:00 2001
+From: Oleksij Rempel <linux@rempel-privat.de>
+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 <o.rempel@pengutronix.de>
+
+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 <stable@vger.kernel.org>
+Reported-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+Reported-by: syzbot+bdf710cfc41c186fdff3@syzkaller.appspotmail.com
+Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From b17233d385d0b6b43ecf81d43008cb1bbb008166 Mon Sep 17 00:00:00 2001
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+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 <s.grosjean@peak-system.com>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 6855ee839699bdabb4b16cf942557fd763bcb1fa Mon Sep 17 00:00:00 2001
+From: Dinh Nguyen <dinguyen@kernel.org>
+Date: Thu, 10 Jun 2021 21:51:59 -0500
+Subject: clk: agilex/stratix10: fix bypass representation
+
+From: Dinh Nguyen <dinguyen@kernel.org>
+
+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 <dinguyen@kernel.org>
+Link: https://lore.kernel.org/r/20210611025201.118799-2-dinguyen@kernel.org
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
+@@ -234,7 +269,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,
+@@ -276,16 +311,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,
--- /dev/null
+From dfd1427c3769ba51297777dbb296f1802d72dbf6 Mon Sep 17 00:00:00 2001
+From: Dinh Nguyen <dinguyen@kernel.org>
+Date: Thu, 10 Jun 2021 21:52:01 -0500
+Subject: clk: agilex/stratix10/n5x: fix how the bypass_reg is handled
+
+From: Dinh Nguyen <dinguyen@kernel.org>
+
+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 <dinguyen@kernel.org>
+Link: https://lore.kernel.org/r/20210611025201.118799-4-dinguyen@kernel.org
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -64,16 +64,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;
+ }
--- /dev/null
+From efbe21df3e889c0f4bf682c2b7e2465d60b0127c Mon Sep 17 00:00:00 2001
+From: Dinh Nguyen <dinguyen@kernel.org>
+Date: Thu, 10 Jun 2021 21:51:58 -0500
+Subject: clk: agilex/stratix10: remove noc_clk
+
+From: Dinh Nguyen <dinguyen@kernel.org>
+
+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 <dinguyen@kernel.org>
+Link: https://lore.kernel.org/r/20210611025201.118799-1-dinguyen@kernel.org
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -222,11 +222,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),
+@@ -252,24 +250,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,
--- /dev/null
+From faa0e307948594b4379a86fff7fb2409067aed6f Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <damien.lemoal@wdc.com>
+Date: Tue, 22 Jun 2021 15:45:02 +0900
+Subject: clk: k210: Fix k210_clk_set_parent()
+
+From: Damien Le Moal <damien.lemoal@wdc.com>
+
+commit faa0e307948594b4379a86fff7fb2409067aed6f upstream.
+
+In k210_clk_set_parent(), add missing writel() call to update the mux
+register of a clock to change its parent. This also fixes a compilation
+warning with clang when compiling with W=1.
+
+Fixes: c6ca7616f7d5 ("clk: Add RISC-V Canaan Kendryte K210 clock driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
+Link: https://lore.kernel.org/r/20210622064502.14841-1-damien.lemoal@wdc.com
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/clk-k210.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/clk/clk-k210.c
++++ b/drivers/clk/clk-k210.c
+@@ -722,6 +722,7 @@ static int k210_clk_set_parent(struct cl
+ reg |= BIT(cfg->mux_bit);
+ else
+ reg &= ~BIT(cfg->mux_bit);
++ writel(reg, ksc->regs + cfg->mux_reg);
+ spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+ return 0;
--- /dev/null
+From c8671c7dc7d51125ab9f651697866bf4a9132277 Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Mon, 26 Apr 2021 10:17:48 +0200
+Subject: crypto: ccp - Annotate SEV Firmware file names
+
+From: Joerg Roedel <jroedel@suse.de>
+
+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 <thomas.lendacky@amd.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From 74c66120fda6596ad57f41e1607b3a5d51ca143d Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Wed, 16 Jun 2021 13:34:59 -0700
+Subject: crypto: nx - Fix memcpy() over-reading in nonce
+
+From: Kees Cook <keescook@chromium.org>
+
+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 <keescook@chromium.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 9eea2904292c2d8fa98df141d3bf7c41ec9dc1b5 Mon Sep 17 00:00:00 2001
+From: Roberto Sassu <roberto.sassu@huawei.com>
+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 <roberto.sassu@huawei.com>
+
+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 <roberto.sassu@huawei.com>
+Cc: stable@vger.kernel.org # 4.5.x
+Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 9acc89d31f0c94c8e573ed61f3e4340bbd526d0c Mon Sep 17 00:00:00 2001
+From: Roberto Sassu <roberto.sassu@huawei.com>
+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 <roberto.sassu@huawei.com>
+
+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 <roberto.sassu@huawei.com>
+Cc: stable@vger.kernel.org # 4.16.x
+Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 ><securityfs>/evm
++
++ another echo can be performed::
++
++ echo 1 ><securityfs>/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 ><securityfs>/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) {
--- /dev/null
+From b9a037b7f3c401d3c63e0423e56aef606b1ffaaf Mon Sep 17 00:00:00 2001
+From: Zhang Yi <yi.zhang@huawei.com>
+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 <yi.zhang@huawei.com>
+
+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 <yi.zhang@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20210507071904.160808-1-yi.zhang@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/super.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -3084,8 +3084,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 {
--- /dev/null
+From 4fb7c70a889ead2e91e184895ac6e5354b759135 Mon Sep 17 00:00:00 2001
+From: Zhang Yi <yi.zhang@huawei.com>
+Date: Sat, 22 May 2021 18:30:45 +0800
+Subject: ext4: correct the cache_nr in tracepoint ext4_es_shrink_exit
+
+From: Zhang Yi <yi.zhang@huawei.com>
+
+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 <yi.zhang@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20210522103045.690103-3-yi.zhang@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From c89849cc0259f3d33624cc3bd127685c3c0fa25d Mon Sep 17 00:00:00 2001
+From: Pan Dong <pandong.peter@bytedance.com>
+Date: Tue, 25 May 2021 15:36:56 +0800
+Subject: ext4: fix avefreec in find_group_orlov
+
+From: Pan Dong <pandong.peter@bytedance.com>
+
+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 <pandong.peter@bytedance.com>
+Link: https://lore.kernel.org/r/20210525073656.31594-1-pandong.peter@bytedance.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From ce3aba43599f0b50adbebff133df8d08a3d5fffe Mon Sep 17 00:00:00 2001
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+Date: Fri, 7 May 2021 00:26:54 +0530
+Subject: ext4: fix kernel infoleak via ext4_extent_header
+
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+
+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 <mail@anirudhrb.com>
+Link: https://lore.kernel.org/r/20210506185655.7118-1-mail@anirudhrb.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From d0b040f5f2557b2f507c01e88ad8cff424fdc6a9 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Mon, 12 Apr 2021 12:23:33 +0200
+Subject: ext4: fix overflow in ext4_iomap_alloc()
+
+From: Jan Kara <jack@suse.cz>
+
+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 <jack@suse.cz>
+Link: https://lore.kernel.org/r/20210412102333.2676-4-jack@suse.cz
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/inode.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/ext4/inode.c
++++ b/fs/ext4/inode.c
+@@ -3420,7 +3420,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;
--- /dev/null
+From e5e7010e5444d923e4091cafff61d05f2d19cada Mon Sep 17 00:00:00 2001
+From: Zhang Yi <yi.zhang@huawei.com>
+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 <yi.zhang@huawei.com>
+
+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 <yi.zhang@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20210522103045.690103-2-yi.zhang@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 8f6840c4fd1e7bd715e403074fb161c1a04cda73 Mon Sep 17 00:00:00 2001
+From: Yang Yingliang <yangyingliang@huawei.com>
+Date: Mon, 10 May 2021 19:10:51 +0800
+Subject: ext4: return error code when ext4_fill_flex_info() fails
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+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 <hulkci@huawei.com>
+Cc: <stable@vger.kernel.org> # v4.18+
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Link: https://lore.kernel.org/r/20210510111051.55650-1-yangyingliang@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/super.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -5039,6 +5039,7 @@ no_journal:
+ ext4_msg(sb, KERN_ERR,
+ "unable to initialize "
+ "flex_bg meta info!");
++ ret = -ENOMEM;
+ goto failed_mount6;
+ }
+
--- /dev/null
+From cd84bbbac12a173a381a64c6ec8b76a5277b87b5 Mon Sep 17 00:00:00 2001
+From: Stephen Brennan <stephen.s.brennan@oracle.com>
+Date: Wed, 23 Jun 2021 16:21:14 -0700
+Subject: ext4: use ext4_grp_locked_error in mb_find_extent
+
+From: Stephen Brennan <stephen.s.brennan@oracle.com>
+
+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: <stable@vger.kernel.org> # 4.14+
+Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
+Reviewed-by: Lukas Czerner <lczerner@redhat.com>
+Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
+Link: https://lore.kernel.org/r/20210623232114.34457-1-stephen.s.brennan@oracle.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/mballoc.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/fs/ext4/mballoc.c
++++ b/fs/ext4/mballoc.c
+@@ -1574,10 +1574,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;
--- /dev/null
+From 4c039d5452691fe80260e4c3dd7b629a095bd0a7 Mon Sep 17 00:00:00 2001
+From: Daniel Rosenberg <drosen@google.com>
+Date: Thu, 3 Jun 2021 09:50:38 +0000
+Subject: f2fs: Advertise encrypted casefolding in sysfs
+
+From: Daniel Rosenberg <drosen@google.com>
+
+commit 4c039d5452691fe80260e4c3dd7b629a095bd0a7 upstream.
+
+Older kernels don't support encryption with casefolding. This adds
+the sysfs entry encrypted_casefold to show support for those combined
+features. Support for this feature was originally added by
+commit 7ad08a58bf67 ("f2fs: Handle casefolding with Encryption")
+
+Fixes: 7ad08a58bf67 ("f2fs: Handle casefolding with Encryption")
+Cc: stable@vger.kernel.org # v5.11+
+Signed-off-by: Daniel Rosenberg <drosen@google.com>
+Reviewed-by: Eric Biggers <ebiggers@google.com>
+Reviewed-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/f2fs/sysfs.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/fs/f2fs/sysfs.c
++++ b/fs/f2fs/sysfs.c
+@@ -525,6 +525,7 @@ enum feat_id {
+ FEAT_CASEFOLD,
+ FEAT_COMPRESSION,
+ FEAT_TEST_DUMMY_ENCRYPTION_V2,
++ FEAT_ENCRYPTED_CASEFOLD,
+ };
+
+ static ssize_t f2fs_feature_show(struct f2fs_attr *a,
+@@ -546,6 +547,7 @@ static ssize_t f2fs_feature_show(struct
+ case FEAT_CASEFOLD:
+ case FEAT_COMPRESSION:
+ case FEAT_TEST_DUMMY_ENCRYPTION_V2:
++ case FEAT_ENCRYPTED_CASEFOLD:
+ return sprintf(buf, "supported\n");
+ }
+ return 0;
+@@ -649,7 +651,10 @@ F2FS_GENERAL_RO_ATTR(avg_vblocks);
+ #ifdef CONFIG_FS_ENCRYPTION
+ F2FS_FEATURE_RO_ATTR(encryption, FEAT_CRYPTO);
+ F2FS_FEATURE_RO_ATTR(test_dummy_encryption_v2, FEAT_TEST_DUMMY_ENCRYPTION_V2);
++#ifdef CONFIG_UNICODE
++F2FS_FEATURE_RO_ATTR(encrypted_casefold, FEAT_ENCRYPTED_CASEFOLD);
+ #endif
++#endif /* CONFIG_FS_ENCRYPTION */
+ #ifdef CONFIG_BLK_DEV_ZONED
+ F2FS_FEATURE_RO_ATTR(block_zoned, FEAT_BLKZONED);
+ #endif
+@@ -739,7 +744,10 @@ static struct attribute *f2fs_feat_attrs
+ #ifdef CONFIG_FS_ENCRYPTION
+ ATTR_LIST(encryption),
+ ATTR_LIST(test_dummy_encryption_v2),
++#ifdef CONFIG_UNICODE
++ ATTR_LIST(encrypted_casefold),
+ #endif
++#endif /* CONFIG_FS_ENCRYPTION */
+ #ifdef CONFIG_BLK_DEV_ZONED
+ ATTR_LIST(block_zoned),
+ #endif
--- /dev/null
+From d927ccfccb009ede24448d69c08b12e7c8a6979b Mon Sep 17 00:00:00 2001
+From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
+Date: Mon, 10 May 2021 20:24:44 +0900
+Subject: f2fs: Prevent swap file in LFS mode
+
+From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
+
+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 <shinichiro.kawasaki@wdc.com>
+Cc: stable@vger.kernel.org # v5.10+
+Reviewed-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/f2fs/data.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/fs/f2fs/data.c
++++ b/fs/f2fs/data.c
+@@ -3971,6 +3971,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;
--- /dev/null
+From 80ef08670d4c28a06a3de954bd350368780bcfef Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi <mszeredi@redhat.com>
+Date: Tue, 22 Jun 2021 09:15:35 +0200
+Subject: fuse: check connected before queueing on fpq->io
+
+From: Miklos Szeredi <mszeredi@redhat.com>
+
+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 <pragalla@codeaurora.org>
+Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts")
+Cc: <stable@vger.kernel.org> # v4.2
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/dev.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/fuse/dev.c
++++ b/fs/fuse/dev.c
+@@ -1272,6 +1272,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;
--- /dev/null
+From e3a43f2a95393000778f8f302d48795add2fc4a8 Mon Sep 17 00:00:00 2001
+From: Greg Kurz <groug@kaod.org>
+Date: Fri, 4 Jun 2021 18:11:51 +0200
+Subject: fuse: Fix crash if superblock of submount gets killed early
+
+From: Greg Kurz <groug@kaod.org>
+
+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 <groug@kaod.org>
+Fixes: bf109c64040f ("fuse: implement crossmounts")
+Cc: stable@vger.kernel.org # v5.10+
+Reviewed-by: Max Reitz <mreitz@redhat.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/dir.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/fs/fuse/dir.c
++++ b/fs/fuse/dir.c
+@@ -346,15 +346,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)) {
--- /dev/null
+From d92d88f0568e97c437eeb79d9c9609bd8277406f Mon Sep 17 00:00:00 2001
+From: Greg Kurz <groug@kaod.org>
+Date: Fri, 4 Jun 2021 18:11:50 +0200
+Subject: fuse: Fix crash in fuse_dentry_automount() error path
+
+From: Greg Kurz <groug@kaod.org>
+
+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 <groug@kaod.org>
+Reviewed-by: Max Reitz <mreitz@redhat.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/dir.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/fs/fuse/dir.c
++++ b/fs/fuse/dir.c
+@@ -339,8 +339,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);
--- /dev/null
+From e4a9ccdd1c03b3dc58214874399d24331ea0a3ab Mon Sep 17 00:00:00 2001
+From: Greg Kurz <groug@kaod.org>
+Date: Fri, 4 Jun 2021 18:11:52 +0200
+Subject: fuse: Fix infinite loop in sget_fc()
+
+From: Greg Kurz <groug@kaod.org>
+
+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 <groug@kaod.org>
+Reviewed-by: Max Reitz <mreitz@redhat.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/dir.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/fs/fuse/dir.c
++++ b/fs/fuse/dir.c
+@@ -352,6 +352,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);
+
--- /dev/null
+From b89ecd60d38ec042d63bdb376c722a16f92bcb88 Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi <mszeredi@redhat.com>
+Date: Fri, 18 Jun 2021 21:16:42 +0200
+Subject: fuse: ignore PG_workingset after stealing
+
+From: Miklos Szeredi <mszeredi@redhat.com>
+
+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 <thomas.lindroth@gmail.com>
+Fixes: 1899ad18c607 ("mm: workingset: tell cache transitions from workingset thrashing")
+Cc: <stable@vger.kernel.org> # v4.20
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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");
--- /dev/null
+From 49221cf86d18bb66fe95d3338cb33bd4b9880ca5 Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi <mszeredi@redhat.com>
+Date: Tue, 22 Jun 2021 09:15:35 +0200
+Subject: fuse: reject internal errno
+
+From: Miklos Szeredi <mszeredi@redhat.com>
+
+commit 49221cf86d18bb66fe95d3338cb33bd4b9880ca5 upstream.
+
+Don't allow userspace to report errors that could be kernel-internal.
+
+Reported-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
+Fixes: 334f485df85a ("[PATCH] FUSE - device functions")
+Cc: <stable@vger.kernel.org> # v2.6.14
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/dev.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/fuse/dev.c
++++ b/fs/fuse/dev.c
+@@ -1867,7 +1867,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);
--- /dev/null
+From 8090d67421ddab0ae932abab5a60200598bf0bbb Mon Sep 17 00:00:00 2001
+From: Stephan Gerhold <stephan@gerhold.net>
+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 <stephan@gerhold.net>
+
+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 <pmeerw@pmeerw.net>
+Fixes: 2017cff24cc0 ("iio:bma180: Add BMA250 chip support")
+Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/20210526094408.34298-2-stephan@gerhold.net
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From f407e2dca0f559621114eeaf657880d83f237fbd Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Sun, 23 May 2021 19:00:56 +0200
+Subject: iio: accel: bmc150: Don't make the remove function of the second accelerometer unregister itself
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit f407e2dca0f559621114eeaf657880d83f237fbd upstream.
+
+On machines with dual accelerometers described in a single ACPI fwnode,
+the bmc150_accel_probe() instantiates a second i2c-client for the second
+accelerometer.
+
+A pointer to this manually instantiated second i2c-client is stored
+inside the iio_dev's private-data through bmc150_set_second_device(),
+so that the i2c-client can be unregistered from bmc150_accel_remove().
+
+Before this commit bmc150_set_second_device() took only 1 argument so it
+would store the pointer in private-data of the iio_dev belonging to the
+manually instantiated i2c-client, leading to the bmc150_accel_remove()
+call for the second_dev trying to unregister *itself* while it was
+being removed, leading to a deadlock and rmmod hanging.
+
+Change bmc150_set_second_device() to take 2 arguments: 1. The i2c-client
+which is instantiating the second i2c-client for the 2nd accelerometer and
+2. The second-device pointer itself (which also is an i2c-client).
+
+This will store the second_device pointer in the private data of the
+iio_dev belonging to the (ACPI instantiated) i2c-client for the first
+accelerometer and will make bmc150_accel_remove() unregister the
+second_device i2c-client when called for the first client,
+avoiding the deadlock.
+
+Fixes: 5bfb3a4bd8f6 ("iio: accel: bmc150: Check for a second ACPI device for BOSC0200")
+Cc: Jeremy Cline <jeremy@jcline.org>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/accel/bmc150-accel-core.c | 4 ++--
+ drivers/iio/accel/bmc150-accel-i2c.c | 2 +-
+ drivers/iio/accel/bmc150-accel.h | 2 +-
+ 3 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/accel/bmc150-accel-core.c
++++ b/drivers/iio/accel/bmc150-accel-core.c
+@@ -1811,11 +1811,11 @@ struct i2c_client *bmc150_get_second_dev
+ }
+ EXPORT_SYMBOL_GPL(bmc150_get_second_device);
+
+-void bmc150_set_second_device(struct i2c_client *client)
++void bmc150_set_second_device(struct i2c_client *client, struct i2c_client *second_dev)
+ {
+ struct bmc150_accel_data *data = iio_priv(i2c_get_clientdata(client));
+
+- data->second_device = client;
++ data->second_device = second_dev;
+ }
+ EXPORT_SYMBOL_GPL(bmc150_set_second_device);
+
+--- a/drivers/iio/accel/bmc150-accel-i2c.c
++++ b/drivers/iio/accel/bmc150-accel-i2c.c
+@@ -70,7 +70,7 @@ static int bmc150_accel_probe(struct i2c
+
+ second_dev = i2c_acpi_new_device(&client->dev, 1, &board_info);
+ if (!IS_ERR(second_dev))
+- bmc150_set_second_device(second_dev);
++ bmc150_set_second_device(client, second_dev);
+ }
+ #endif
+
+--- a/drivers/iio/accel/bmc150-accel.h
++++ b/drivers/iio/accel/bmc150-accel.h
+@@ -18,7 +18,7 @@ int bmc150_accel_core_probe(struct devic
+ const char *name, bool block_supported);
+ int bmc150_accel_core_remove(struct device *dev);
+ struct i2c_client *bmc150_get_second_device(struct i2c_client *second_device);
+-void bmc150_set_second_device(struct i2c_client *second_device);
++void bmc150_set_second_device(struct i2c_client *client, struct i2c_client *second_dev);
+ extern const struct dev_pm_ops bmc150_accel_pm_ops;
+ extern const struct regmap_config bmc150_regmap_conf;
+
--- /dev/null
+From 6e2a90af0b8d757e850cc023d761ee9a9492e2fe Mon Sep 17 00:00:00 2001
+From: Stephan Gerhold <stephan@gerhold.net>
+Date: Fri, 11 Jun 2021 10:08:54 +0200
+Subject: iio: accel: bmc150: Fix bma222 scale unit
+
+From: Stephan Gerhold <stephan@gerhold.net>
+
+commit 6e2a90af0b8d757e850cc023d761ee9a9492e2fe upstream.
+
+According to sysfs-bus-iio documentation the unit for accelerometer
+values after applying scale/offset should be m/s^2, not g, which explains
+why the scale values for the other variants in bmc150-accel do not match
+exactly the values given in the datasheet.
+
+To get the correct values, we need to multiply the BMA222 scale values
+by g = 9.80665 m/s^2.
+
+Fixes: a1a210bf29a1 ("iio: accel: bmc150-accel: Add support for BMA222")
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
+Link: https://lore.kernel.org/r/20210611080903.14384-2-stephan@gerhold.net
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/accel/bmc150-accel-core.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/accel/bmc150-accel-core.c
++++ b/drivers/iio/accel/bmc150-accel-core.c
+@@ -1171,11 +1171,12 @@ static const struct bmc150_accel_chip_in
+ /*
+ * The datasheet page 17 says:
+ * 15.6, 31.3, 62.5 and 125 mg per LSB.
++ * IIO unit is m/s^2 so multiply by g = 9.80665 m/s^2.
+ */
+- .scale_table = { {156000, BMC150_ACCEL_DEF_RANGE_2G},
+- {313000, BMC150_ACCEL_DEF_RANGE_4G},
+- {625000, BMC150_ACCEL_DEF_RANGE_8G},
+- {1250000, BMC150_ACCEL_DEF_RANGE_16G} },
++ .scale_table = { {152984, BMC150_ACCEL_DEF_RANGE_2G},
++ {306948, BMC150_ACCEL_DEF_RANGE_4G},
++ {612916, BMC150_ACCEL_DEF_RANGE_8G},
++ {1225831, BMC150_ACCEL_DEF_RANGE_16G} },
+ },
+ [bma222e] = {
+ .name = "BMA222E",
--- /dev/null
+From f2bf22dc9ea8ead180fc0221874bd556bf1d2685 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Sun, 23 May 2021 19:00:55 +0200
+Subject: iio: accel: bmc150: Fix dereferencing the wrong pointer in bmc150_get/set_second_device
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit f2bf22dc9ea8ead180fc0221874bd556bf1d2685 upstream.
+
+The drvdata for iio-parent devices points to the struct iio_dev for
+the iio-device. So by directly casting the return from i2c_get_clientdata()
+to struct bmc150_accel_data * the code was ending up storing the second_dev
+pointer in (and retrieving it from) some semi-random offset inside
+struct iio_dev, rather then storing it in the second_dev member of the
+bmc150_accel_data struct.
+
+Fix the code to get the struct bmc150_accel_data * pointer to call
+iio_priv() on the struct iio_dev * returned by i2c_get_clientdata(),
+so that the correct pointer gets dereferenced.
+
+This fixes the following oops on rmmod, caused by trying to
+dereference the wrong return of bmc150_get_second_device():
+
+[ 238.980737] BUG: unable to handle page fault for address: 0000000000004710
+[ 238.980755] #PF: supervisor read access in kernel mode
+[ 238.980760] #PF: error_code(0x0000) - not-present page
+...
+[ 238.980841] i2c_unregister_device.part.0+0x19/0x60
+[ 238.980856] 0xffffffffc0815016
+[ 238.980863] i2c_device_remove+0x25/0xb0
+[ 238.980869] __device_release_driver+0x180/0x240
+[ 238.980876] driver_detach+0xd4/0x120
+[ 238.980882] bus_remove_driver+0x5b/0xd0
+[ 238.980888] i2c_del_driver+0x44/0x70
+
+While at it also remove the now no longer sensible checks for data
+being NULL, iio_priv never returns NULL for an iio_dev with non 0
+sized private-data.
+
+Fixes: 5bfb3a4bd8f6 ("iio: accel: bmc150: Check for a second ACPI device for BOSC0200")
+Cc: Jeremy Cline <jeremy@jcline.org>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/accel/bmc150-accel-core.c | 10 +++-------
+ 1 file changed, 3 insertions(+), 7 deletions(-)
+
+--- a/drivers/iio/accel/bmc150-accel-core.c
++++ b/drivers/iio/accel/bmc150-accel-core.c
+@@ -1805,10 +1805,7 @@ EXPORT_SYMBOL_GPL(bmc150_accel_core_prob
+
+ struct i2c_client *bmc150_get_second_device(struct i2c_client *client)
+ {
+- struct bmc150_accel_data *data = i2c_get_clientdata(client);
+-
+- if (!data)
+- return NULL;
++ struct bmc150_accel_data *data = iio_priv(i2c_get_clientdata(client));
+
+ return data->second_device;
+ }
+@@ -1816,10 +1813,9 @@ EXPORT_SYMBOL_GPL(bmc150_get_second_devi
+
+ void bmc150_set_second_device(struct i2c_client *client)
+ {
+- struct bmc150_accel_data *data = i2c_get_clientdata(client);
++ struct bmc150_accel_data *data = iio_priv(i2c_get_clientdata(client));
+
+- if (data)
+- data->second_device = client;
++ data->second_device = client;
+ }
+ EXPORT_SYMBOL_GPL(bmc150_set_second_device);
+
--- /dev/null
+From c8cc4cf60b000fb9f4b29bed131fb6cf1fe42d67 Mon Sep 17 00:00:00 2001
+From: Yang Yingliang <yangyingliang@huawei.com>
+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 <yangyingliang@huawei.com>
+
+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 <hulkci@huawei.com>
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/20210601142605.3613605-1-yangyingliang@huawei.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 7cd04c863f9e1655d607705455e7714f24451984 Mon Sep 17 00:00:00 2001
+From: frank zago <frank@zago.net>
+Date: Mon, 26 Apr 2021 21:20:17 -0500
+Subject: iio: light: tcs3472: do not free unallocated IRQ
+
+From: frank zago <frank@zago.net>
+
+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 <frank@zago.net>
+Link: https://lore.kernel.org/r/20210427022017.19314-2-frank@zago.net
+Fixes: 9d2f715d592e ("iio: light: tcs3472: support out-of-threshold events")
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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));
+
--- /dev/null
+From 71b33f6f93ef9462c84560e2236ed22209d26a58 Mon Sep 17 00:00:00 2001
+From: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
+Date: Thu, 10 Jun 2021 15:46:18 +0200
+Subject: iio: ltr501: ltr501_read_ps(): add missing endianness conversion
+
+From: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
+
+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 <Oliver.Lang@gossenmetrawatt.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
+Link: https://lore.kernel.org/r/20210610134619.2101372-4-mkl@pengutronix.de
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From 421a26f3d7a7c3ca43f3a9dc0f3cb0f562d5bd95 Mon Sep 17 00:00:00 2001
+From: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
+Date: Thu, 10 Jun 2021 15:46:17 +0200
+Subject: iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTR
+
+From: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
+
+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 <Oliver.Lang@gossenmetrawatt.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
+Link: https://lore.kernel.org/r/20210610134619.2101372-3-mkl@pengutronix.de
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From 2ac0b029a04b673ce83b5089368f467c5dca720c Mon Sep 17 00:00:00 2001
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+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 <mkl@pengutronix.de>
+
+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 <Oliver.Lang@gossenmetrawatt.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
+Link: https://lore.kernel.org/r/20210610134619.2101372-2-mkl@pengutronix.de
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From b33bb78a1fada6445c265c585ee0dd0fc6279102 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Tue, 22 Jun 2021 10:22:44 -0700
+Subject: KVM: nVMX: Handle split-lock #AC exceptions that happen in L2
+
+From: Sean Christopherson <seanjc@google.com>
+
+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 <xiaoyao.li@intel.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210622172244.3561540-1-seanjc@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -5775,6 +5775,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
+@@ -4796,7 +4796,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;
+@@ -4905,7 +4905,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
+@@ -379,6 +379,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 vmx_update_exception_bitmap(struct kvm_vcpu *vcpu);
+ void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
+ bool vmx_nmi_blocked(struct kvm_vcpu *vcpu);
--- /dev/null
+From 51696f39cbee5bb684e7959c0c98b5f54548aa34 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Mon, 21 Jun 2021 11:24:40 -0700
+Subject: KVM: PPC: Book3S HV: Workaround high stack usage with clang
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+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 <lkp@intel.com>
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+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 <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -53,7 +53,8 @@ void kvmhv_save_hv_regs(struct kvm_vcpu
+ hr->dawrx1 = vcpu->arch.dawrx1;
+ }
+
+-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;
+
--- /dev/null
+From 49c6f8756cdffeb9af1fbcb86bacacced26465d7 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Tue, 22 Jun 2021 10:56:51 -0700
+Subject: KVM: x86: Force all MMUs to reinitialize if guest CPUID is modified
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 49c6f8756cdffeb9af1fbcb86bacacced26465d7 upstream.
+
+Invalidate all MMUs' roles after a CPUID update to force reinitizliation
+of the MMU context/helpers. Despite the efforts of commit de3ccd26fafc
+("KVM: MMU: record maximum physical address width in kvm_mmu_extended_role"),
+there are still a handful of CPUID-based properties that affect MMU
+behavior but are not incorporated into mmu_role. E.g. 1gb hugepage
+support, AMD vs. Intel handling of bit 8, and SEV's C-Bit location all
+factor into the guest's reserved PTE bits.
+
+The obvious alternative would be to add all such properties to mmu_role,
+but doing so provides no benefit over simply forcing a reinitialization
+on every CPUID update, as setting guest CPUID is a rare operation.
+
+Note, reinitializing all MMUs after a CPUID update does not fix all of
+KVM's woes. Specifically, kvm_mmu_page_role doesn't track the CPUID
+properties, which means that a vCPU can reuse shadow pages that should
+not exist for the new vCPU model, e.g. that map GPAs that are now illegal
+(due to MAXPHYADDR changes) or that set bits that are now reserved
+(PAGE_SIZE for 1gb pages), etc...
+
+Tracking the relevant CPUID properties in kvm_mmu_page_role would address
+the majority of problems, but fully tracking that much state in the
+shadow page role comes with an unpalatable cost as it would require a
+non-trivial increase in KVM's memory footprint. The GBPAGES case is even
+worse, as neither Intel nor AMD provides a way to disable 1gb hugepage
+support in the hardware page walker, i.e. it's a virtualization hole that
+can't be closed when using TDP.
+
+In other words, resetting the MMU after a CPUID update is largely a
+superficial fix. But, it will allow reverting the tracking of MAXPHYADDR
+in the mmu_role, and that case in particular needs to mostly work because
+KVM's shadow_root_level depends on guest MAXPHYADDR when 5-level paging
+is supported. For cases where KVM botches guest behavior, the damage is
+limited to that guest. But for the shadow_root_level, a misconfigured
+MMU can cause KVM to incorrectly access memory, e.g. due to walking off
+the end of its shadow page tables.
+
+Fixes: 7dcd57552008 ("x86/kvm/mmu: check if tdp/shadow MMU reconfiguration is needed")
+Cc: Yu Zhang <yu.c.zhang@linux.intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210622175739.3610207-7-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/kvm_host.h | 1 +
+ arch/x86/kvm/cpuid.c | 6 +++---
+ arch/x86/kvm/mmu/mmu.c | 12 ++++++++++++
+ 3 files changed, 16 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/include/asm/kvm_host.h
++++ b/arch/x86/include/asm/kvm_host.h
+@@ -1433,6 +1433,7 @@ void kvm_mmu_set_mask_ptes(u64 user_mask
+ u64 dirty_mask, u64 nx_mask, u64 x_mask, u64 p_mask,
+ u64 acc_track_mask, u64 me_mask);
+
++void kvm_mmu_after_set_cpuid(struct kvm_vcpu *vcpu);
+ void kvm_mmu_reset_context(struct kvm_vcpu *vcpu);
+ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
+ struct kvm_memory_slot *memslot,
+--- a/arch/x86/kvm/cpuid.c
++++ b/arch/x86/kvm/cpuid.c
+@@ -185,10 +185,10 @@ static void kvm_vcpu_after_set_cpuid(str
+ static_call(kvm_x86_vcpu_after_set_cpuid)(vcpu);
+
+ /*
+- * Except for the MMU, which needs to be reset after any vendor
+- * specific adjustments to the reserved GPA bits.
++ * Except for the MMU, which needs to do its thing any vendor specific
++ * adjustments to the reserved GPA bits.
+ */
+- kvm_mmu_reset_context(vcpu);
++ kvm_mmu_after_set_cpuid(vcpu);
+ }
+
+ static int is_efer_nx(void)
+--- a/arch/x86/kvm/mmu/mmu.c
++++ b/arch/x86/kvm/mmu/mmu.c
+@@ -4846,6 +4846,18 @@ kvm_mmu_calc_root_page_role(struct kvm_v
+ return role.base;
+ }
+
++void kvm_mmu_after_set_cpuid(struct kvm_vcpu *vcpu)
++{
++ /*
++ * Invalidate all MMU roles to force them to reinitialize as CPUID
++ * information is factored into reserved bit calculations.
++ */
++ vcpu->arch.root_mmu.mmu_role.ext.valid = 0;
++ vcpu->arch.guest_mmu.mmu_role.ext.valid = 0;
++ vcpu->arch.nested_mmu.mmu_role.ext.valid = 0;
++ kvm_mmu_reset_context(vcpu);
++}
++
+ void kvm_mmu_reset_context(struct kvm_vcpu *vcpu)
+ {
+ kvm_mmu_unload(vcpu);
--- /dev/null
+From 112022bdb5bc372e00e6e43cb88ee38ea67b97bd Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+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 <seanjc@google.com>
+
+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 <seanjc@google.com>
+Message-Id: <20210622175739.3610207-3-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -4155,7 +4155,15 @@ static inline u64 reserved_hpa_bits(void
+ 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;
--- /dev/null
+From ef318b9edf66a082f23d00d79b70c17b4c055a26 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+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 <seanjc@google.com>
+
+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 <seanjc@google.com>
+Message-Id: <20210622175739.3610207-5-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 0aa1837533e5f4be8cc21bbc06314c23ba2c5447 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Tue, 22 Jun 2021 10:56:48 -0700
+Subject: KVM: x86: Properly reset MMU context at vCPU RESET/INIT
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 0aa1837533e5f4be8cc21bbc06314c23ba2c5447 upstream.
+
+Reset the MMU context at vCPU INIT (and RESET for good measure) if CR0.PG
+was set prior to INIT. Simply re-initializing the current MMU is not
+sufficient as the current root HPA may not be usable in the new context.
+E.g. if TDP is disabled and INIT arrives while the vCPU is in long mode,
+KVM will fail to switch to the 32-bit pae_root and bomb on the next
+VM-Enter due to running with a 64-bit CR3 in 32-bit mode.
+
+This bug was papered over in both VMX and SVM, but still managed to rear
+its head in the MMU role on VMX. Because EFER.LMA=1 requires CR0.PG=1,
+kvm_calc_shadow_mmu_root_page_role() checks for EFER.LMA without first
+checking CR0.PG. VMX's RESET/INIT flow writes CR0 before EFER, and so
+an INIT with the vCPU in 64-bit mode will cause the hack-a-fix to
+generate the wrong MMU role.
+
+In VMX, the INIT issue is specific to running without unrestricted guest
+since unrestricted guest is available if and only if EPT is enabled.
+Commit 8668a3c468ed ("KVM: VMX: Reset mmu context when entering real
+mode") resolved the issue by forcing a reset when entering emulated real
+mode.
+
+In SVM, commit ebae871a509d ("kvm: svm: reset mmu on VCPU reset") forced
+a MMU reset on every INIT to workaround the flaw in common x86. Note, at
+the time the bug was fixed, the SVM problem was exacerbated by a complete
+lack of a CR4 update.
+
+The vendor resets will be reverted in future patches, primarily to aid
+bisection in case there are non-INIT flows that rely on the existing VMX
+logic.
+
+Because CR0.PG is unconditionally cleared on INIT, and because CR0.WP and
+all CR4/EFER paging bits are ignored if CR0.PG=0, simply checking that
+CR0.PG was '1' prior to INIT/RESET is sufficient to detect a required MMU
+context reset.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210622175739.3610207-4-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -10302,6 +10302,8 @@ void kvm_arch_vcpu_destroy(struct kvm_vc
+
+ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
+ {
++ unsigned long old_cr0 = kvm_read_cr0(vcpu);
++
+ kvm_lapic_reset(vcpu, init_event);
+
+ vcpu->arch.hflags = 0;
+@@ -10370,6 +10372,17 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcp
+ vcpu->arch.ia32_xss = 0;
+
+ static_call(kvm_x86_vcpu_reset)(vcpu, init_event);
++
++ /*
++ * Reset the MMU context if paging was enabled prior to INIT (which is
++ * implied if CR0.PG=1 as CR0 will be '0' prior to RESET). Unlike the
++ * standard CR0/CR4/EFER modification paths, only CR0.PG needs to be
++ * checked because it is unconditionally cleared on INIT and all other
++ * paging related bits are ignored if paging is disabled, i.e. CR0.WP,
++ * CR4, and EFER changes are all irrelevant if CR0.PG was '0'.
++ */
++ if (old_cr0 & X86_CR0_PG)
++ kvm_mmu_reset_context(vcpu);
+ }
+
+ void kvm_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu, u8 vector)
--- /dev/null
+From 2b9ac22b12a266eb4fec246a07b504dd4983b16b Mon Sep 17 00:00:00 2001
+From: Kristian Klausen <kristian@klausen.dk>
+Date: Fri, 18 Jun 2021 13:51:57 +0200
+Subject: loop: Fix missing discard support when using LOOP_CONFIGURE
+
+From: Kristian Klausen <kristian@klausen.dk>
+
+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: <stable@vger.kernel.org> # 5.8.x-
+Fixes: 3448914e8cc5 ("loop: Add LOOP_CONFIGURE ioctl")
+Signed-off-by: Kristian Klausen <kristian@klausen.dk>
+Link: https://lore.kernel.org/r/20210618115157.31452-1-kristian@klausen.dk
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/loop.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/block/loop.c
++++ b/drivers/block/loop.c
+@@ -1153,6 +1153,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);
--- /dev/null
+From 95f83ee8d857f006813755e89a126f1048b001e8 Mon Sep 17 00:00:00 2001
+From: Abinaya Kalaiselvan <akalaise@codeaurora.org>
+Date: Wed, 23 Jun 2021 20:10:44 +0530
+Subject: mac80211: fix NULL ptr dereference during mesh peer connection for non HE devices
+
+From: Abinaya Kalaiselvan <akalaise@codeaurora.org>
+
+commit 95f83ee8d857f006813755e89a126f1048b001e8 upstream.
+
+"sband->iftype_data" is not assigned with any value for non HE supported
+devices, which causes NULL pointer access during mesh peer connection
+in those devices. Fix this by accessing the pointer after HE
+capabilities condition check.
+
+Cc: stable@vger.kernel.org
+Fixes: 7f7aa94bcaf0 (mac80211: reduce peer HE MCS/NSS to own capabilities)
+Signed-off-by: Abinaya Kalaiselvan <akalaise@codeaurora.org>
+Link: https://lore.kernel.org/r/1624459244-4497-1-git-send-email-akalaise@codeaurora.org
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/he.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/net/mac80211/he.c
++++ b/net/mac80211/he.c
+@@ -111,7 +111,7 @@ ieee80211_he_cap_ie_to_sta_he_cap(struct
+ struct sta_info *sta)
+ {
+ struct ieee80211_sta_he_cap *he_cap = &sta->sta.he_cap;
+- struct ieee80211_sta_he_cap own_he_cap = sband->iftype_data->he_cap;
++ struct ieee80211_sta_he_cap own_he_cap;
+ struct ieee80211_he_cap_elem *he_cap_ie_elem = (void *)he_cap_ie;
+ u8 he_ppe_size;
+ u8 mcs_nss_size;
+@@ -123,6 +123,8 @@ ieee80211_he_cap_ie_to_sta_he_cap(struct
+ if (!he_cap_ie || !ieee80211_get_he_sta_cap(sband))
+ return;
+
++ own_he_cap = sband->iftype_data->he_cap;
++
+ /* Make sure size is OK */
+ mcs_nss_size = ieee80211_he_mcs_nss_size(he_cap_ie_elem);
+ he_ppe_size =
--- /dev/null
+From e41eb3e408de27982a5f8f50b2dd8002bed96908 Mon Sep 17 00:00:00 2001
+From: Felix Fietkau <nbd@nbd.name>
+Date: Sat, 19 Jun 2021 12:15:17 +0200
+Subject: mac80211: remove iwlwifi specific workaround that broke sta NDP tx
+
+From: Felix Fietkau <nbd@nbd.name>
+
+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 <nbd@nbd.name>
+Link: https://lore.kernel.org/r/20210619101517.90806-1-nbd@nbd.name
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -1032,6 +1032,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;
--- /dev/null
+From c24d37322548a6ec3caec67100d28b9c1f89f60a Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+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 <jannh@google.com>
+
+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 <jannh@google.com>
+Reviewed-by: John Hubbard <jhubbard@nvidia.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Kirill A. Shutemov <kirill@shutemov.name>
+Cc: Jan Kara <jack@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
+@@ -95,6 +127,14 @@ __maybe_unused struct page *try_grab_com
+ 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().
+@@ -102,15 +142,10 @@ __maybe_unused struct page *try_grab_com
+ * 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);
+@@ -134,14 +169,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);
+ }
+
+ /**
--- /dev/null
+From 4c1daba15c209b99d192f147fea3dade30f72ed2 Mon Sep 17 00:00:00 2001
+From: Robin Murphy <robin.murphy@arm.com>
+Date: Tue, 8 Jun 2021 12:55:12 +0100
+Subject: perf/smmuv3: Don't trample existing events with global filter
+
+From: Robin Murphy <robin.murphy@arm.com>
+
+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 <robin.murphy@arm.com>
+Link: https://lore.kernel.org/r/32c80c0e46237f49ad8da0c9f8864e13c4a803aa.1623153312.git.robin.murphy@arm.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -277,7 +277,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) :
+@@ -285,17 +285,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;
+ }
+
--- /dev/null
+From d18216fafecf2a3a7c2b97086892269d6ab3cd5e Mon Sep 17 00:00:00 2001
+From: Kan Liang <kan.liang@linux.intel.com>
+Date: Fri, 18 Jun 2021 08:12:53 -0700
+Subject: perf/x86/intel: Add more events requires FRONTEND MSR on Sapphire Rapids
+
+From: Kan Liang <kan.liang@linux.intel.com>
+
+commit d18216fafecf2a3a7c2b97086892269d6ab3cd5e upstream.
+
+On Sapphire Rapids, there are two more events 0x40ad and 0x04c2 which
+rely on the FRONTEND MSR. If the FRONTEND MSR is not set correctly, the
+count value is not correct.
+
+Update intel_spr_extra_regs[] to support them.
+
+Fixes: 61b985e3e775 ("perf/x86/intel: Add perf core PMU support for Sapphire Rapids")
+Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/1624029174-122219-3-git-send-email-kan.liang@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/events/intel/core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/events/intel/core.c
++++ b/arch/x86/events/intel/core.c
+@@ -280,6 +280,8 @@ static struct extra_reg intel_spr_extra_
+ INTEL_UEVENT_EXTRA_REG(0x012b, MSR_OFFCORE_RSP_1, 0x3fffffffffull, RSP_1),
+ INTEL_UEVENT_PEBS_LDLAT_EXTRA_REG(0x01cd),
+ INTEL_UEVENT_EXTRA_REG(0x01c6, MSR_PEBS_FRONTEND, 0x7fff17, FE),
++ INTEL_UEVENT_EXTRA_REG(0x40ad, MSR_PEBS_FRONTEND, 0x7, FE),
++ INTEL_UEVENT_EXTRA_REG(0x04c2, MSR_PEBS_FRONTEND, 0x8, FE),
+ EVENT_EXTRA_END
+ };
+
--- /dev/null
+From 1d5c7880992a06679585e7e568cc679c0c5fd4f2 Mon Sep 17 00:00:00 2001
+From: Kan Liang <kan.liang@linux.intel.com>
+Date: Fri, 18 Jun 2021 08:12:54 -0700
+Subject: perf/x86/intel: Fix instructions:ppp support in Sapphire Rapids
+
+From: Kan Liang <kan.liang@linux.intel.com>
+
+commit 1d5c7880992a06679585e7e568cc679c0c5fd4f2 upstream.
+
+Perf errors out when sampling instructions:ppp.
+
+$ perf record -e instructions:ppp -- true
+Error:
+The sys_perf_event_open() syscall returned with 22 (Invalid argument)
+for event (instructions:ppp).
+
+The instruction PDIR is only available on the fixed counter 0. The event
+constraint has been updated to fixed0_constraint in
+icl_get_event_constraints(). The Sapphire Rapids codes unconditionally
+error out for the event which is not available on the GP counter 0.
+
+Make the instructions:ppp an exception.
+
+Fixes: 61b985e3e775 ("perf/x86/intel: Add perf core PMU support for Sapphire Rapids")
+Reported-by: Yasin, Ahmad <ahmad.yasin@intel.com>
+Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/1624029174-122219-4-git-send-email-kan.liang@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/events/intel/core.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/events/intel/core.c
++++ b/arch/x86/events/intel/core.c
+@@ -3975,8 +3975,10 @@ spr_get_event_constraints(struct cpu_hw_
+ * The :ppp indicates the Precise Distribution (PDist) facility, which
+ * is only supported on the GP counter 0. If a :ppp event which is not
+ * available on the GP counter 0, error out.
++ * Exception: Instruction PDIR is only available on the fixed counter 0.
+ */
+- if (event->attr.precise_ip == 3) {
++ if ((event->attr.precise_ip == 3) &&
++ !constraint_match(&fixed0_constraint, event->hw.config)) {
+ if (c->idxmsk64 & BIT_ULL(0))
+ return &counter0_constraint;
+
--- /dev/null
+From 7c6986ade69e3c81bac831645bc72109cd798a80 Mon Sep 17 00:00:00 2001
+From: Michael Ellerman <mpe@ellerman.id.au>
+Date: Fri, 25 Jun 2021 16:28:41 +1000
+Subject: powerpc/stacktrace: Fix spurious "stale" traces in raise_backtrace_ipi()
+
+From: Michael Ellerman <mpe@ellerman.id.au>
+
+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 <nathanl@linux.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20210625140408.3351173-1-mpe@ellerman.id.au
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From b1c3a24897bd528f2f4fda9fea7da08a84ae25b6 Mon Sep 17 00:00:00 2001
+From: Marek Vasut <marex@denx.de>
+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 <marex@denx.de>
+
+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 <marex@denx.de>
+Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com>
+Cc: Angus Ainslie <angus@akkea.ca>
+Cc: David S. Miller <davem@davemloft.net>
+Cc: Jakub Kicinski <kuba@kernel.org>
+Cc: Kalle Valo <kvalo@codeaurora.org>
+Cc: Karun Eagalapati <karun256@gmail.com>
+Cc: Martin Kepplinger <martink@posteo.de>
+Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
+Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
+Cc: Siva Rebbagondla <siva8118@gmail.com>
+Cc: netdev@vger.kernel.org
+Cc: stable@vger.kernel.org
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20210507213105.140138-1-marex@denx.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 314538041b5632ffaf64798faaeabaf2793fe029 Mon Sep 17 00:00:00 2001
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Date: Tue, 1 Jun 2021 18:19:53 +0200
+Subject: rsi: fix AP mode with WPA failure due to encrypted EAPOL
+
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+
+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 <martin.fuzzey@flowbird.group>
+Fixes: 38ef62353acb ("rsi: security enhancements for AP mode")
+CC: stable@vger.kernel.org
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/1622564459-24430-1-git-send-email-martin.fuzzey@flowbird.group
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ };
--- /dev/null
+From 950ac33dbe6ff656a623d862022f0762ec061ba7 Mon Sep 17 00:00:00 2001
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Date: Mon, 7 Jun 2021 19:36:40 +0200
+Subject: rtc: stm32: Fix unbalanced clk_disable_unprepare() on probe error path
+
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+
+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] [<c0111148>] (unwind_backtrace) from [<c010c0b8>] (show_stack+0x10/0x14)
+[ 15.687371] [<c010c0b8>] (show_stack) from [<c0ab3d28>] (dump_stack+0xc0/0xe0)
+[ 15.694574] [<c0ab3d28>] (dump_stack) from [<c012360c>] (__warn+0xc8/0xf0)
+[ 15.701428] [<c012360c>] (__warn) from [<c0123694>] (warn_slowpath_fmt+0x60/0x94)
+[ 15.708894] [<c0123694>] (warn_slowpath_fmt) from [<c053b518>] (clk_core_disable+0xb0/0xc8)
+[ 15.717230] [<c053b518>] (clk_core_disable) from [<c053c190>] (clk_core_disable_lock+0x18/0x24)
+[ 15.725924] [<c053c190>] (clk_core_disable_lock) from [<bf0adc44>] (stm32_rtc_probe+0x124/0x5e4 [rtc_stm32])
+[ 15.735739] [<bf0adc44>] (stm32_rtc_probe [rtc_stm32]) from [<c05f7d4c>] (platform_drv_probe+0x48/0x98)
+[ 15.745095] [<c05f7d4c>] (platform_drv_probe) from [<c05f5cec>] (really_probe+0x1f0/0x458)
+[ 15.753338] [<c05f5cec>] (really_probe) from [<c05f61c4>] (driver_probe_device+0x70/0x1c4)
+[ 15.761584] [<c05f61c4>] (driver_probe_device) from [<c05f6580>] (device_driver_attach+0x58/0x60)
+[ 15.770439] [<c05f6580>] (device_driver_attach) from [<c05f6654>] (__driver_attach+0xcc/0x170)
+[ 15.779032] [<c05f6654>] (__driver_attach) from [<c05f40d8>] (bus_for_each_dev+0x58/0x7c)
+[ 15.787191] [<c05f40d8>] (bus_for_each_dev) from [<c05f4ffc>] (bus_add_driver+0xdc/0x1f8)
+[ 15.795352] [<c05f4ffc>] (bus_add_driver) from [<c05f6ed8>] (driver_register+0x7c/0x110)
+[ 15.803425] [<c05f6ed8>] (driver_register) from [<c01027bc>] (do_one_initcall+0x70/0x1b8)
+[ 15.811588] [<c01027bc>] (do_one_initcall) from [<c01a1094>] (do_init_module+0x58/0x1f8)
+[ 15.819660] [<c01a1094>] (do_init_module) from [<c01a0074>] (load_module+0x1e58/0x23c8)
+[ 15.827646] [<c01a0074>] (load_module) from [<c01a0860>] (sys_finit_module+0xa0/0xd4)
+[ 15.835459] [<c01a0860>] (sys_finit_module) from [<c01011e0>] (__sys_trace_return+0x0/0x20)
+
+Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
+Cc: stable@vger.kernel.org
+Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Link: https://lore.kernel.org/r/1623087421-19722-1-git-send-email-martin.fuzzey@flowbird.group
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 Mon Sep 17 00:00:00 2001
+From: Vineeth Vijayan <vneethv@linux.ibm.com>
+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 <vneethv@linux.ibm.com>
+
+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: <stable@vger.kernel.org>
+Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
+Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -801,8 +801,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
+ */
--- /dev/null
+From 85b18d7b5e7ffefb2f076186511d39c4990aa005 Mon Sep 17 00:00:00 2001
+From: Janosch Frank <frankja@linux.ibm.com>
+Date: Tue, 12 Jan 2021 05:40:53 -0500
+Subject: s390: mm: Fix secure storage access exception handling
+
+From: Janosch Frank <frankja@linux.ibm.com>
+
+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 <frankja@linux.ibm.com>
+Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Fixes: 084ea4d611a3d ("s390/mm: add (non)secure page access exceptions handlers")
+Cc: stable@vger.kernel.org
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -791,6 +791,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;
--- /dev/null
+From 6a2cbc58d6c9d90cd74288cc497c2b45815bc064 Mon Sep 17 00:00:00 2001
+From: Yun Zhou <yun.zhou@windriver.com>
+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 <yun.zhou@windriver.com>
+
+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 <yun.zhou@windriver.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 9078204ca5c33ba20443a8623a41a68a9995a70d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali@kernel.org>
+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 <pali@kernel.org>
+
+commit 9078204ca5c33ba20443a8623a41a68a9995a70d upstream.
+
+The clock divisor should be rounded to the closest value.
+
+Signed-off-by: Pali Rohár <pali@kernel.org>
+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 <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 08a84410a04f05c7c1b8e833f552416d8eb9f6fe Mon Sep 17 00:00:00 2001
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Date: Thu, 10 Jun 2021 20:08:06 +0900
+Subject: serial: sh-sci: Stop dmaengine transfer in sci_stop_tx()
+
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+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: <stable@vger.kernel.org> # v4.9+
+Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Link: https://lore.kernel.org/r/20210610110806.277932-1-yoshihiro.shimoda.uh@renesas.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From d495dd743d5ecd47288156e25c4d9163294a0992 Mon Sep 17 00:00:00 2001
+From: Ondrej Zary <linux@zary.sk>
+Date: Fri, 11 Jun 2021 22:19:40 +0200
+Subject: serial_cs: Add Option International GSM-Ready 56K/ISDN modem
+
+From: Ondrej Zary <linux@zary.sk>
+
+commit d495dd743d5ecd47288156e25c4d9163294a0992 upstream.
+
+Add support for Option International GSM-Ready 56K/ISDN PCMCIA modem
+card.
+
+Signed-off-by: Ondrej Zary <linux@zary.sk>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210611201940.23898-2-linux@zary.sk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -777,6 +777,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),
--- /dev/null
+From 11b1d881a90fc184cc7d06e9804eb288c24a2a0d Mon Sep 17 00:00:00 2001
+From: Ondrej Zary <linux@zary.sk>
+Date: Fri, 11 Jun 2021 22:19:39 +0200
+Subject: serial_cs: remove wrong GLOBETROTTER.cis entry
+
+From: Ondrej Zary <linux@zary.sk>
+
+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 <linux@zary.sk>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210611201940.23898-1-linux@zary.sk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -805,7 +805,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),
iov_iter_fault_in_readable-should-do-nothing-in-xarray-case.patch
input-elants_i2c-fix-null-dereference-at-probing.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-zoned-print-message-when-zone-sanity-check-type-fails.patch
+btrfs-zoned-bail-out-if-we-can-t-read-a-reliable-write-pointer.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-fix-unbalanced-unlock-in-qgroup_account_snapshot.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
+mac80211-fix-null-ptr-dereference-during-mesh-peer-connection-for-non-he-devices.patch
+sunrpc-fix-the-batch-tasks-count-wraparound.patch
+sunrpc-should-wake-up-the-privileged-task-firstly.patch
+bus-mhi-core-fix-power-down-latency.patch
+bus-mhi-wait-for-m2-state-during-system-resume.patch
+bus-mhi-pci-generic-add-missing-pci_disable_pcie_error_reporting-calls.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
+kvm-x86-properly-reset-mmu-context-at-vcpu-reset-init.patch
+kvm-x86-force-all-mmus-to-reinitialize-if-guest-cpuid-is-modified.patch
+s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch
+s390-mm-fix-secure-storage-access-exception-handling.patch
+f2fs-advertise-encrypted-casefolding-in-sysfs.patch
+f2fs-prevent-swap-file-in-lfs-mode.patch
+clk-k210-fix-k210_clk_set_parent.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
+iio-accel-bmc150-fix-bma222-scale-unit.patch
+iio-accel-bmc150-fix-dereferencing-the-wrong-pointer-in-bmc150_get-set_second_device.patch
+iio-accel-bmc150-don-t-make-the-remove-function-of-the-second-accelerometer-unregister-itself.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
+x86-gpu-add-jasperlake-to-gen11-early-quirks.patch
+perf-x86-intel-add-more-events-requires-frontend-msr-on-sapphire-rapids.patch
+perf-x86-intel-fix-instructions-ppp-support-in-sapphire-rapids.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
--- /dev/null
+From 47ec636f7a25aa2549e198c48ecb6b1c25d05456 Mon Sep 17 00:00:00 2001
+From: Michael Buesch <m@bues.ch>
+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 <m@bues.ch>
+
+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 <m@bues.ch>
+Cc: stable@vger.kernel.org
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20210515210252.318be2ba@wiggum
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From fcb170a9d825d7db4a3fb870b0300f5a40a8d096 Mon Sep 17 00:00:00 2001
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Date: Sat, 26 Jun 2021 15:50:41 +0800
+Subject: SUNRPC: Fix the batch tasks count wraparound.
+
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+
+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 <hulkci@huawei.com>
+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 <zhangxiaoxu5@huawei.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 5483b904bf336948826594610af4c9bbb0d9e3aa Mon Sep 17 00:00:00 2001
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Date: Sat, 26 Jun 2021 15:50:42 +0800
+Subject: SUNRPC: Should wake up the privileged task firstly.
+
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+
+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 <hulkci@huawei.com>
+Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode")
+Cc: stable@vger.kernel.org
+Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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];
--- /dev/null
+From 9913d5745bd720c4266805c8d29952a3702e4eca Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Tue, 29 Jun 2021 09:40:10 -0400
+Subject: tracepoint: Add tracepoint_probe_register_may_exist() for BPF tracing
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+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 <syzbot+721aa903751db87aa244@syzkaller.appspotmail.com>
+Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Tested-by: syzbot+721aa903751db87aa244@syzkaller.appspotmail.com
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -2143,7 +2143,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
+@@ -273,7 +273,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;
+@@ -288,7 +289,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);
+ }
+
+@@ -344,6 +345,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
+@@ -366,7 +393,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;
+ }
--- /dev/null
+From 26c563731056c3ee66f91106c3078a8c36bb7a9e Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Wed, 7 Jul 2021 11:08:21 -0400
+Subject: tracing/histograms: Fix parsing of "sym-offset" modifier
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+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 <mingo@kernel.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 100719dcef447 ("tracing: Add simple expression support to hist triggers")
+Reviewed-by: Tom Zanussi <zanussi@kernel.org>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 31b77c70d9bc04d3b024ea56c129523f9edc1328 Mon Sep 17 00:00:00 2001
+From: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
+Date: Tue, 8 Jun 2021 11:04:11 +0530
+Subject: x86/gpu: add JasperLake to gen11 early quirks
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
+
+commit 31b77c70d9bc04d3b024ea56c129523f9edc1328 upstream.
+
+Let's reserve JSL stolen memory for graphics.
+
+JasperLake is a gen11 platform which is compatible with
+ICL/EHL changes.
+
+This was missed in commit 24ea098b7c0d ("drm/i915/jsl: Split
+EHL/JSL platform info and PCI ids")
+
+V2:
+ - Added maintainer list in cc
+ - Added patch ref in commit message
+V1:
+ - Added Cc: x86@kernel.org
+
+Fixes: 24ea098b7c0d ("drm/i915/jsl: Split EHL/JSL platform info and PCI ids")
+Cc: <stable@vger.kernel.org> # v5.11+
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: x86@kernel.org
+Cc: José Roberto de Souza <jose.souza@intel.com>
+Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
+Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210608053411.394166-1-tejaskumarx.surendrakumar.upadhyay@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/early-quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kernel/early-quirks.c
++++ b/arch/x86/kernel/early-quirks.c
+@@ -549,6 +549,7 @@ static const struct pci_device_id intel_
+ INTEL_CNL_IDS(&gen9_early_ops),
+ INTEL_ICL_11_IDS(&gen11_early_ops),
+ INTEL_EHL_IDS(&gen11_early_ops),
++ INTEL_JSL_IDS(&gen11_early_ops),
+ INTEL_TGL_12_IDS(&gen11_early_ops),
+ INTEL_RKL_IDS(&gen11_early_ops),
+ };
projects / thirdparty / kernel / stable-queue.git / commitdiff
