From: Greg Kroah-Hartman Date: Sat, 2 Apr 2022 13:08:41 +0000 (+0200) Subject: 5.17-stable patches X-Git-Tag: v5.17.2~179 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ccda0fe3eede6ef3113221519ad08f7b19d261f6;p=thirdparty%2Fkernel%2Fstable-queue.git 5.17-stable patches added patches: brcmfmac-firmware-allocate-space-for-default-boardrev-in-nvram.patch brcmfmac-pcie-declare-missing-firmware-files-in-pcie.c.patch brcmfmac-pcie-fix-crashes-due-to-early-irqs.patch brcmfmac-pcie-release-firmwares-in-the-brcmf_pcie_setup-error-path.patch brcmfmac-pcie-replace-brcmf_pcie_copy_mem_todev-with-memcpy_toio.patch btrfs-extend-locking-to-all-space_info-members-accesses.patch btrfs-verify-the-tranisd-of-the-to-be-written-dirty-extent-buffer.patch btrfs-zoned-mark-relocation-as-writing.patch drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch drm-i915-gem-add-missing-boundary-check-in-vm_access.patch drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch drm-nouveau-backlight-fix-lvds-backlight-detection-on-some-laptops.patch drm-nouveau-backlight-just-set-all-backlight-types-as-raw.patch drm-syncobj-flatten-dma_fence_chains-on-transfer.patch kvm-s390x-fix-sck-locking.patch mips-always-permit-to-build-u-boot-images.patch pci-imx6-allow-to-probe-when-dw_pcie_wait_for_link-fails.patch pci-pciehp-clear-cmd_busy-bit-in-polling-mode.patch pci-xgene-revert-pci-xgene-fix-ib-window-setup.patch pci-xgene-revert-pci-xgene-use-inbound-resources-for-setup.patch xtensa-define-update_mmu_tlb-function.patch xtensa-fix-stop_machine_cpuslocked-call-in-patch_text.patch xtensa-fix-xtensa_wsr-always-writing-0.patch --- diff --git a/queue-5.17/brcmfmac-firmware-allocate-space-for-default-boardrev-in-nvram.patch b/queue-5.17/brcmfmac-firmware-allocate-space-for-default-boardrev-in-nvram.patch new file mode 100644 index 00000000000..b2327479d86 --- /dev/null +++ b/queue-5.17/brcmfmac-firmware-allocate-space-for-default-boardrev-in-nvram.patch @@ -0,0 +1,36 @@ +From d19d8e3ba256f81ea4a27209dbbd1f0a00ef1903 Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Tue, 1 Feb 2022 01:07:06 +0900 +Subject: brcmfmac: firmware: Allocate space for default boardrev in nvram + +From: Hector Martin + +commit d19d8e3ba256f81ea4a27209dbbd1f0a00ef1903 upstream. + +If boardrev is missing from the NVRAM we add a default one, but this +might need more space in the output buffer than was allocated. Ensure +we have enough padding for this in the buffer. + +Fixes: 46f2b38a91b0 ("brcmfmac: insert default boardrev in nvram data if missing") +Reviewed-by: Arend van Spriel +Cc: stable@vger.kernel.org +Signed-off-by: Hector Martin +Reviewed-by: Andy Shevchenko +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220131160713.245637-3-marcan@marcan.st +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c +@@ -207,6 +207,8 @@ static int brcmf_init_nvram_parser(struc + size = BRCMF_FW_MAX_NVRAM_SIZE; + else + size = data_len; ++ /* Add space for properties we may add */ ++ size += strlen(BRCMF_FW_DEFAULT_BOARDREV) + 1; + /* Alloc for extra 0 byte + roundup by 4 + length field */ + size += 1 + 3 + sizeof(u32); + nvp->nvram = kzalloc(size, GFP_KERNEL); diff --git a/queue-5.17/brcmfmac-pcie-declare-missing-firmware-files-in-pcie.c.patch b/queue-5.17/brcmfmac-pcie-declare-missing-firmware-files-in-pcie.c.patch new file mode 100644 index 00000000000..59e2e3769af --- /dev/null +++ b/queue-5.17/brcmfmac-pcie-declare-missing-firmware-files-in-pcie.c.patch @@ -0,0 +1,51 @@ +From 6d766d8cb505ec1fae63da8faef4fc5712c3d794 Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Tue, 1 Feb 2022 01:07:08 +0900 +Subject: brcmfmac: pcie: Declare missing firmware files in pcie.c + +From: Hector Martin + +commit 6d766d8cb505ec1fae63da8faef4fc5712c3d794 upstream. + +Move one of the declarations from sdio.c to pcie.c, since it makes no +sense in the former (SDIO support is optional), and add missing ones. + +Fixes: 75729e110e68 ("brcmfmac: expose firmware config files through modinfo") +Reviewed-by: Linus Walleij +Reviewed-by: Arend van Spriel +Cc: stable@vger.kernel.org +Signed-off-by: Hector Martin +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220131160713.245637-5-marcan@marcan.st +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 7 +++++++ + drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 - + 2 files changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +@@ -59,6 +59,13 @@ BRCMF_FW_DEF(4366B, "brcmfmac4366b-pcie" + BRCMF_FW_DEF(4366C, "brcmfmac4366c-pcie"); + BRCMF_FW_DEF(4371, "brcmfmac4371-pcie"); + ++/* firmware config files */ ++MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.txt"); ++MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.txt"); ++ ++/* per-board firmware binaries */ ++MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.bin"); ++ + static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = { + BRCMF_FW_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFF, 43602), + BRCMF_FW_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C), +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +@@ -629,7 +629,6 @@ BRCMF_FW_CLM_DEF(43752, "brcmfmac43752-s + + /* firmware config files */ + MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-sdio.*.txt"); +-MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.txt"); + + /* per-board firmware binaries */ + MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-sdio.*.bin"); diff --git a/queue-5.17/brcmfmac-pcie-fix-crashes-due-to-early-irqs.patch b/queue-5.17/brcmfmac-pcie-fix-crashes-due-to-early-irqs.patch new file mode 100644 index 00000000000..852b44cb5e7 --- /dev/null +++ b/queue-5.17/brcmfmac-pcie-fix-crashes-due-to-early-irqs.patch @@ -0,0 +1,66 @@ +From b50255c83b914defd61a57fbc81d452334b63f4c Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Tue, 1 Feb 2022 01:07:10 +0900 +Subject: brcmfmac: pcie: Fix crashes due to early IRQs + +From: Hector Martin + +commit b50255c83b914defd61a57fbc81d452334b63f4c upstream. + +The driver was enabling IRQs before the message processing was +initialized. This could cause IRQs to come in too early and crash the +driver. Instead, move the IRQ enable and hostready to a bus preinit +function, at which point everything is properly initialized. + +Fixes: 9e37f045d5e7 ("brcmfmac: Adding PCIe bus layer support.") +Reviewed-by: Linus Walleij +Reviewed-by: Arend van Spriel +Cc: stable@vger.kernel.org +Signed-off-by: Hector Martin +Reviewed-by: Andy Shevchenko +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220131160713.245637-7-marcan@marcan.st +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 16 +++++++++++++--- + 1 file changed, 13 insertions(+), 3 deletions(-) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +@@ -1315,6 +1315,18 @@ static void brcmf_pcie_down(struct devic + { + } + ++static int brcmf_pcie_preinit(struct device *dev) ++{ ++ struct brcmf_bus *bus_if = dev_get_drvdata(dev); ++ struct brcmf_pciedev *buspub = bus_if->bus_priv.pcie; ++ ++ brcmf_dbg(PCIE, "Enter\n"); ++ ++ brcmf_pcie_intr_enable(buspub->devinfo); ++ brcmf_pcie_hostready(buspub->devinfo); ++ ++ return 0; ++} + + static int brcmf_pcie_tx(struct device *dev, struct sk_buff *skb) + { +@@ -1423,6 +1435,7 @@ static int brcmf_pcie_reset(struct devic + } + + static const struct brcmf_bus_ops brcmf_pcie_bus_ops = { ++ .preinit = brcmf_pcie_preinit, + .txdata = brcmf_pcie_tx, + .stop = brcmf_pcie_down, + .txctl = brcmf_pcie_tx_ctlpkt, +@@ -1795,9 +1808,6 @@ static void brcmf_pcie_setup(struct devi + + init_waitqueue_head(&devinfo->mbdata_resp_wait); + +- brcmf_pcie_intr_enable(devinfo); +- brcmf_pcie_hostready(devinfo); +- + ret = brcmf_attach(&devinfo->pdev->dev); + if (ret) + goto fail; diff --git a/queue-5.17/brcmfmac-pcie-release-firmwares-in-the-brcmf_pcie_setup-error-path.patch b/queue-5.17/brcmfmac-pcie-release-firmwares-in-the-brcmf_pcie_setup-error-path.patch new file mode 100644 index 00000000000..ca8ad03adb1 --- /dev/null +++ b/queue-5.17/brcmfmac-pcie-release-firmwares-in-the-brcmf_pcie_setup-error-path.patch @@ -0,0 +1,36 @@ +From 5e90f0f3ead014867dade7a22f93958119f5efab Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Tue, 1 Feb 2022 01:07:05 +0900 +Subject: brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path + +From: Hector Martin + +commit 5e90f0f3ead014867dade7a22f93958119f5efab upstream. + +This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that +the CLM blob is released in the device remove path. + +Fixes: 82f93cf46d60 ("brcmfmac: get chip's default RAM info during PCIe setup") +Reviewed-by: Linus Walleij +Reviewed-by: Arend van Spriel +Cc: stable@vger.kernel.org +Signed-off-by: Hector Martin +Reviewed-by: Andy Shevchenko +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220131160713.245637-2-marcan@marcan.st +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +@@ -1777,6 +1777,8 @@ static void brcmf_pcie_setup(struct devi + ret = brcmf_chip_get_raminfo(devinfo->ci); + if (ret) { + brcmf_err(bus, "Failed to get RAM info\n"); ++ release_firmware(fw); ++ brcmf_fw_nvram_free(nvram); + goto fail; + } + diff --git a/queue-5.17/brcmfmac-pcie-replace-brcmf_pcie_copy_mem_todev-with-memcpy_toio.patch b/queue-5.17/brcmfmac-pcie-replace-brcmf_pcie_copy_mem_todev-with-memcpy_toio.patch new file mode 100644 index 00000000000..3270895131d --- /dev/null +++ b/queue-5.17/brcmfmac-pcie-replace-brcmf_pcie_copy_mem_todev-with-memcpy_toio.patch @@ -0,0 +1,108 @@ +From 9466987f246758eb7e9071ae58005253f631271e Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Tue, 1 Feb 2022 01:07:09 +0900 +Subject: brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio + +From: Hector Martin + +commit 9466987f246758eb7e9071ae58005253f631271e upstream. + +The alignment check was wrong (e.g. & 4 instead of & 3), and the logic +was also inefficient if the length was not a multiple of 4, since it +would needlessly fall back to copying the entire buffer bytewise. + +We already have a perfectly good memcpy_toio function, so just call that +instead of rolling our own copy logic here. brcmf_pcie_init_ringbuffers +was already using it anyway. + +Fixes: 9e37f045d5e7 ("brcmfmac: Adding PCIe bus layer support.") +Reviewed-by: Linus Walleij +Reviewed-by: Arend van Spriel +Reviewed-by: Andy Shevchenko +Cc: stable@vger.kernel.org +Signed-off-by: Hector Martin +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220131160713.245637-6-marcan@marcan.st +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 48 +--------------- + 1 file changed, 4 insertions(+), 44 deletions(-) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +@@ -12,6 +12,7 @@ + #include + #include + #include ++#include + #include + + #include +@@ -455,47 +456,6 @@ brcmf_pcie_write_ram32(struct brcmf_pcie + + + static void +-brcmf_pcie_copy_mem_todev(struct brcmf_pciedev_info *devinfo, u32 mem_offset, +- void *srcaddr, u32 len) +-{ +- void __iomem *address = devinfo->tcm + mem_offset; +- __le32 *src32; +- __le16 *src16; +- u8 *src8; +- +- if (((ulong)address & 4) || ((ulong)srcaddr & 4) || (len & 4)) { +- if (((ulong)address & 2) || ((ulong)srcaddr & 2) || (len & 2)) { +- src8 = (u8 *)srcaddr; +- while (len) { +- iowrite8(*src8, address); +- address++; +- src8++; +- len--; +- } +- } else { +- len = len / 2; +- src16 = (__le16 *)srcaddr; +- while (len) { +- iowrite16(le16_to_cpu(*src16), address); +- address += 2; +- src16++; +- len--; +- } +- } +- } else { +- len = len / 4; +- src32 = (__le32 *)srcaddr; +- while (len) { +- iowrite32(le32_to_cpu(*src32), address); +- address += 4; +- src32++; +- len--; +- } +- } +-} +- +- +-static void + brcmf_pcie_copy_dev_tomem(struct brcmf_pciedev_info *devinfo, u32 mem_offset, + void *dstaddr, u32 len) + { +@@ -1570,8 +1530,8 @@ static int brcmf_pcie_download_fw_nvram( + return err; + + brcmf_dbg(PCIE, "Download FW %s\n", devinfo->fw_name); +- brcmf_pcie_copy_mem_todev(devinfo, devinfo->ci->rambase, +- (void *)fw->data, fw->size); ++ memcpy_toio(devinfo->tcm + devinfo->ci->rambase, ++ (void *)fw->data, fw->size); + + resetintr = get_unaligned_le32(fw->data); + release_firmware(fw); +@@ -1585,7 +1545,7 @@ static int brcmf_pcie_download_fw_nvram( + brcmf_dbg(PCIE, "Download NVRAM %s\n", devinfo->nvram_name); + address = devinfo->ci->rambase + devinfo->ci->ramsize - + nvram_len; +- brcmf_pcie_copy_mem_todev(devinfo, address, nvram, nvram_len); ++ memcpy_toio(devinfo->tcm + address, nvram, nvram_len); + brcmf_fw_nvram_free(nvram); + } else { + brcmf_dbg(PCIE, "No matching NVRAM file found %s\n", diff --git a/queue-5.17/btrfs-extend-locking-to-all-space_info-members-accesses.patch b/queue-5.17/btrfs-extend-locking-to-all-space_info-members-accesses.patch new file mode 100644 index 00000000000..6bf37834133 --- /dev/null +++ b/queue-5.17/btrfs-extend-locking-to-all-space_info-members-accesses.patch @@ -0,0 +1,49 @@ +From 06bae876634ebf837ba70ea3de532b288326103d Mon Sep 17 00:00:00 2001 +From: Niels Dossche +Date: Fri, 25 Feb 2022 22:20:28 +0100 +Subject: btrfs: extend locking to all space_info members accesses + +From: Niels Dossche + +commit 06bae876634ebf837ba70ea3de532b288326103d upstream. + +bytes_pinned is always accessed under space_info->lock, except in +btrfs_preempt_reclaim_metadata_space, however the other members are +accessed under that lock. The reserved member of the rsv's are also +partially accessed under a lock and partially not. Move all these +accesses into the same lock to ensure consistency. + +This could potentially race and lead to a flush instead of a commit but +it's not a big problem as it's only for preemptive flush. + +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Johannes Thumshirn +Reviewed-by: Josef Bacik +Signed-off-by: Niels Dossche +Signed-off-by: Niels Dossche +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/space-info.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/space-info.c ++++ b/fs/btrfs/space-info.c +@@ -1061,7 +1061,6 @@ static void btrfs_preempt_reclaim_metada + trans_rsv->reserved; + if (block_rsv_size < space_info->bytes_may_use) + delalloc_size = space_info->bytes_may_use - block_rsv_size; +- spin_unlock(&space_info->lock); + + /* + * We don't want to include the global_rsv in our calculation, +@@ -1092,6 +1091,8 @@ static void btrfs_preempt_reclaim_metada + flush = FLUSH_DELAYED_REFS_NR; + } + ++ spin_unlock(&space_info->lock); ++ + /* + * We don't want to reclaim everything, just a portion, so scale + * down the to_reclaim by 1/4. If it takes us down to 0, diff --git a/queue-5.17/btrfs-verify-the-tranisd-of-the-to-be-written-dirty-extent-buffer.patch b/queue-5.17/btrfs-verify-the-tranisd-of-the-to-be-written-dirty-extent-buffer.patch new file mode 100644 index 00000000000..0b35d02ccf7 --- /dev/null +++ b/queue-5.17/btrfs-verify-the-tranisd-of-the-to-be-written-dirty-extent-buffer.patch @@ -0,0 +1,96 @@ +From 3777369ff1518b579560611a0d0c33f930154f64 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Wed, 2 Mar 2022 09:10:21 +0800 +Subject: btrfs: verify the tranisd of the to-be-written dirty extent buffer + +From: Qu Wenruo + +commit 3777369ff1518b579560611a0d0c33f930154f64 upstream. + +[BUG] +There is a bug report that a bitflip in the transid part of an extent +buffer makes btrfs to reject certain tree blocks: + + BTRFS error (device dm-0): parent transid verify failed on 1382301696 wanted 262166 found 22 + +[CAUSE] +Note the failed transid check, hex(262166) = 0x40016, while +hex(22) = 0x16. + +It's an obvious bitflip. + +Furthermore, the reporter also confirmed the bitflip is from the +hardware, so it's a real hardware caused bitflip, and such problem can +not be detected by the existing tree-checker framework. + +As tree-checker can only verify the content inside one tree block, while +generation of a tree block can only be verified against its parent. + +So such problem remain undetected. + +[FIX] +Although tree-checker can not verify it at write-time, we still have a +quick (but not the most accurate) way to catch such obvious corruption. + +Function csum_one_extent_buffer() is called before we submit metadata +write. + +Thus it means, all the extent buffer passed in should be dirty tree +blocks, and should be newer than last committed transaction. + +Using that we can catch the above bitflip. + +Although it's not a perfect solution, as if the corrupted generation is +higher than the correct value, we have no way to catch it at all. + +Reported-by: Christoph Anton Mitterer +Link: https://lore.kernel.org/linux-btrfs/2dfcbc130c55cc6fd067b93752e90bd2b079baca.camel@scientia.org/ +CC: stable@vger.kernel.org # 5.15+ +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/disk-io.c | 26 ++++++++++++++++++++------ + 1 file changed, 20 insertions(+), 6 deletions(-) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -441,17 +441,31 @@ static int csum_one_extent_buffer(struct + else + ret = btrfs_check_leaf_full(eb); + +- if (ret < 0) { +- btrfs_print_tree(eb, 0); ++ if (ret < 0) ++ goto error; ++ ++ /* ++ * Also check the generation, the eb reached here must be newer than ++ * last committed. Or something seriously wrong happened. ++ */ ++ if (unlikely(btrfs_header_generation(eb) <= fs_info->last_trans_committed)) { ++ ret = -EUCLEAN; + btrfs_err(fs_info, +- "block=%llu write time tree block corruption detected", +- eb->start); +- WARN_ON(IS_ENABLED(CONFIG_BTRFS_DEBUG)); +- return ret; ++ "block=%llu bad generation, have %llu expect > %llu", ++ eb->start, btrfs_header_generation(eb), ++ fs_info->last_trans_committed); ++ goto error; + } + write_extent_buffer(eb, result, 0, fs_info->csum_size); + + return 0; ++ ++error: ++ btrfs_print_tree(eb, 0); ++ btrfs_err(fs_info, "block=%llu write time tree block corruption detected", ++ eb->start); ++ WARN_ON(IS_ENABLED(CONFIG_BTRFS_DEBUG)); ++ return ret; + } + + /* Checksum all dirty extent buffers in one bio_vec */ diff --git a/queue-5.17/btrfs-zoned-mark-relocation-as-writing.patch b/queue-5.17/btrfs-zoned-mark-relocation-as-writing.patch new file mode 100644 index 00000000000..e71ccc2ab2a --- /dev/null +++ b/queue-5.17/btrfs-zoned-mark-relocation-as-writing.patch @@ -0,0 +1,92 @@ +From ca5e4ea0beaec8bc674121838bf8614c089effb9 Mon Sep 17 00:00:00 2001 +From: Naohiro Aota +Date: Fri, 18 Feb 2022 13:14:19 +0900 +Subject: btrfs: zoned: mark relocation as writing + +From: Naohiro Aota + +commit ca5e4ea0beaec8bc674121838bf8614c089effb9 upstream. + +There is a hung_task issue with running generic/068 on an SMR +device. The hang occurs while a process is trying to thaw the +filesystem. The process is trying to take sb->s_umount to thaw the +FS. The lock is held by fsstress, which calls btrfs_sync_fs() and is +waiting for an ordered extent to finish. However, as the FS is frozen, +the ordered extents never finish. + +Having an ordered extent while the FS is frozen is the root cause of +the hang. The ordered extent is initiated from btrfs_relocate_chunk() +which is called from btrfs_reclaim_bgs_work(). + +This commit adds sb_*_write() around btrfs_relocate_chunk() call +site. For the usual "btrfs balance" command, we already call it with +mnt_want_file() in btrfs_ioctl_balance(). + +Fixes: 18bb8bbf13c1 ("btrfs: zoned: automatically reclaim zones") +CC: stable@vger.kernel.org # 5.13+ +Link: https://github.com/naota/linux/issues/56 +Reviewed-by: Johannes Thumshirn +Signed-off-by: Naohiro Aota +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/block-group.c | 8 +++++++- + fs/btrfs/volumes.c | 3 +++ + 2 files changed, 10 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/block-group.c ++++ b/fs/btrfs/block-group.c +@@ -1522,8 +1522,12 @@ void btrfs_reclaim_bgs_work(struct work_ + if (!test_bit(BTRFS_FS_OPEN, &fs_info->flags)) + return; + +- if (!btrfs_exclop_start(fs_info, BTRFS_EXCLOP_BALANCE)) ++ sb_start_write(fs_info->sb); ++ ++ if (!btrfs_exclop_start(fs_info, BTRFS_EXCLOP_BALANCE)) { ++ sb_end_write(fs_info->sb); + return; ++ } + + /* + * Long running balances can keep us blocked here for eternity, so +@@ -1531,6 +1535,7 @@ void btrfs_reclaim_bgs_work(struct work_ + */ + if (!mutex_trylock(&fs_info->reclaim_bgs_lock)) { + btrfs_exclop_finish(fs_info); ++ sb_end_write(fs_info->sb); + return; + } + +@@ -1605,6 +1610,7 @@ next: + spin_unlock(&fs_info->unused_bgs_lock); + mutex_unlock(&fs_info->reclaim_bgs_lock); + btrfs_exclop_finish(fs_info); ++ sb_end_write(fs_info->sb); + } + + void btrfs_reclaim_bgs(struct btrfs_fs_info *fs_info) +--- a/fs/btrfs/volumes.c ++++ b/fs/btrfs/volumes.c +@@ -8299,10 +8299,12 @@ static int relocating_repair_kthread(voi + target = cache->start; + btrfs_put_block_group(cache); + ++ sb_start_write(fs_info->sb); + if (!btrfs_exclop_start(fs_info, BTRFS_EXCLOP_BALANCE)) { + btrfs_info(fs_info, + "zoned: skip relocating block group %llu to repair: EBUSY", + target); ++ sb_end_write(fs_info->sb); + return -EBUSY; + } + +@@ -8330,6 +8332,7 @@ out: + btrfs_put_block_group(cache); + mutex_unlock(&fs_info->reclaim_bgs_lock); + btrfs_exclop_finish(fs_info); ++ sb_end_write(fs_info->sb); + + return ret; + } diff --git a/queue-5.17/drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch b/queue-5.17/drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch new file mode 100644 index 00000000000..f28d43a0e57 --- /dev/null +++ b/queue-5.17/drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch @@ -0,0 +1,67 @@ +From cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c Mon Sep 17 00:00:00 2001 +From: Thomas Zimmermann +Date: Tue, 1 Feb 2022 12:53:05 +0100 +Subject: drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB + +From: Thomas Zimmermann + +commit cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c upstream. + +Mark screen buffers in system memory with FBINFO_VIRTFB. Otherwise, fbdev +deferred I/O marks mmap'ed areas of system memory with VM_IO. (There's an +inverse relationship between the two flags.) + +For shadow buffers, also set the FBINFO_READS_FAST hint. + +v3: + * change FB_ to FBINFO_ in commit description +v2: + * updated commit description (Daniel) + * added Fixes tag + +Signed-off-by: Thomas Zimmermann +Fixes: d536540f304c ("drm/fb-helper: Add generic fbdev emulation .fb_probe function") +Reviewed-by: Daniel Vetter +Cc: dri-devel@lists.freedesktop.org +Cc: # v4.19+ +Link: https://patchwork.freedesktop.org/patch/msgid/20220201115305.9333-1-tzimmermann@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_fb_helper.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/drm_fb_helper.c ++++ b/drivers/gpu/drm/drm_fb_helper.c +@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(s + fbi->fbops = &drm_fbdev_fb_ops; + fbi->screen_size = sizes->surface_height * fb->pitches[0]; + fbi->fix.smem_len = fbi->screen_size; ++ fbi->flags = FBINFO_DEFAULT; + + drm_fb_helper_fill_info(fbi, fb_helper, sizes); + +@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(s + fbi->screen_buffer = vzalloc(fbi->screen_size); + if (!fbi->screen_buffer) + return -ENOMEM; ++ fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST; + + fbi->fbdefio = &drm_fbdev_defio; +- + fb_deferred_io_init(fbi); + } else { + /* buffer is mapped for HW framebuffer */ + ret = drm_client_buffer_vmap(fb_helper->buffer, &map); + if (ret) + return ret; +- if (map.is_iomem) ++ if (map.is_iomem) { + fbi->screen_base = map.vaddr_iomem; +- else ++ } else { + fbi->screen_buffer = map.vaddr; ++ fbi->flags |= FBINFO_VIRTFB; ++ } + + /* + * Shamelessly leak the physical address to user-space. As diff --git a/queue-5.17/drm-i915-gem-add-missing-boundary-check-in-vm_access.patch b/queue-5.17/drm-i915-gem-add-missing-boundary-check-in-vm_access.patch new file mode 100644 index 00000000000..4de26a2286c --- /dev/null +++ b/queue-5.17/drm-i915-gem-add-missing-boundary-check-in-vm_access.patch @@ -0,0 +1,82 @@ +From 3886a86e7e6cc6ce2ce93c440fecd8f42aed0ce7 Mon Sep 17 00:00:00 2001 +From: Mastan Katragadda +Date: Thu, 3 Mar 2022 11:34:28 +0530 +Subject: drm/i915/gem: add missing boundary check in vm_access + +From: Mastan Katragadda + +commit 3886a86e7e6cc6ce2ce93c440fecd8f42aed0ce7 upstream. + +A missing bounds check in vm_access() can lead to an out-of-bounds read +or write in the adjacent memory area, since the len attribute is not +validated before the memcpy later in the function, potentially hitting: + +[ 183.637831] BUG: unable to handle page fault for address: ffffc90000c86000 +[ 183.637934] #PF: supervisor read access in kernel mode +[ 183.637997] #PF: error_code(0x0000) - not-present page +[ 183.638059] PGD 100000067 P4D 100000067 PUD 100258067 PMD 106341067 PTE 0 +[ 183.638144] Oops: 0000 [#2] PREEMPT SMP NOPTI +[ 183.638201] CPU: 3 PID: 1790 Comm: poc Tainted: G D 5.17.0-rc6-ci-drm-11296+ #1 +[ 183.638298] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319 05/30/2019 +[ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10 +[ 183.640213] RSP: 0018:ffffc90001763d48 EFLAGS: 00010246 +[ 183.641117] RAX: ffff888109c14000 RBX: ffff888111bece40 RCX: 0000000000000ffc +[ 183.642029] RDX: 0000000000001000 RSI: ffffc90000c86000 RDI: ffff888109c14004 +[ 183.642946] RBP: 0000000000000ffc R08: 800000000000016b R09: 0000000000000000 +[ 183.643848] R10: ffffc90000c85000 R11: 0000000000000048 R12: 0000000000001000 +[ 183.644742] R13: ffff888111bed190 R14: ffff888109c14000 R15: 0000000000001000 +[ 183.645653] FS: 00007fe5ef807540(0000) GS:ffff88845b380000(0000) knlGS:0000000000000000 +[ 183.646570] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 183.647481] CR2: ffffc90000c86000 CR3: 000000010ff02006 CR4: 00000000003706e0 +[ 183.648384] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 183.649271] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 183.650142] Call Trace: +[ 183.650988] +[ 183.651793] vm_access+0x1f0/0x2a0 [i915] +[ 183.652726] __access_remote_vm+0x224/0x380 +[ 183.653561] mem_rw.isra.0+0xf9/0x190 +[ 183.654402] vfs_read+0x9d/0x1b0 +[ 183.655238] ksys_read+0x63/0xe0 +[ 183.656065] do_syscall_64+0x38/0xc0 +[ 183.656882] entry_SYSCALL_64_after_hwframe+0x44/0xae +[ 183.657663] RIP: 0033:0x7fe5ef725142 +[ 183.659351] RSP: 002b:00007ffe1e81c7e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 +[ 183.660227] RAX: ffffffffffffffda RBX: 0000557055dfb780 RCX: 00007fe5ef725142 +[ 183.661104] RDX: 0000000000001000 RSI: 00007ffe1e81d880 RDI: 0000000000000005 +[ 183.661972] RBP: 00007ffe1e81e890 R08: 0000000000000030 R09: 0000000000000046 +[ 183.662832] R10: 0000557055dfc2e0 R11: 0000000000000246 R12: 0000557055dfb1c0 +[ 183.663691] R13: 00007ffe1e81e980 R14: 0000000000000000 R15: 0000000000000000 + +Changes since v1: + - Updated if condition with range_overflows_t [Chris Wilson] + +Fixes: 9f909e215fea ("drm/i915: Implement vm_ops->access for gdb access into mmaps") +Signed-off-by: Mastan Katragadda +Suggested-by: Adam Zabrocki +Reported-by: Jackson Cody +Cc: Chris Wilson +Cc: Jon Bloomfield +Cc: Sudeep Dutt +Cc: # v5.8+ +Reviewed-by: Matthew Auld +[mauld: tidy up the commit message and add Cc: stable] +Signed-off-by: Matthew Auld +Link: https://patchwork.freedesktop.org/patch/msgid/20220303060428.1668844-1-mastanx.katragadda@intel.com +(cherry picked from commit 661412e301e2ca86799aa4f400d1cf0bd38c57c6) +Signed-off-by: Joonas Lahtinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c ++++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c +@@ -439,7 +439,7 @@ vm_access(struct vm_area_struct *area, u + return -EACCES; + + addr -= area->vm_start; +- if (addr >= obj->base.size) ++ if (range_overflows_t(u64, addr, len, obj->base.size)) + return -EINVAL; + + i915_gem_ww_ctx_init(&ww, true); diff --git a/queue-5.17/drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch b/queue-5.17/drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch new file mode 100644 index 00000000000..0cd97177a7d --- /dev/null +++ b/queue-5.17/drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch @@ -0,0 +1,60 @@ +From 24a644ebbfd3b13cda702f98907f9dd123e34bf9 Mon Sep 17 00:00:00 2001 +From: Jani Nikula +Date: Thu, 10 Feb 2022 12:36:42 +0200 +Subject: drm/i915/opregion: check port number bounds for SWSCI display power state +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jani Nikula + +commit 24a644ebbfd3b13cda702f98907f9dd123e34bf9 upstream. + +The mapping from enum port to whatever port numbering scheme is used by +the SWSCI Display Power State Notification is odd, and the memory of it +has faded. In any case, the parameter only has space for ports numbered +[0..4], and UBSAN reports bit shift beyond it when the platform has port +F or more. + +Since the SWSCI functionality is supposed to be obsolete for new +platforms (i.e. ones that might have port F or more), just bail out +early if the mapped and mangled port number is beyond what the Display +Power State Notification can support. + +Fixes: 9c4b0a683193 ("drm/i915: add opregion function to notify bios of encoder enable/disable") +Cc: # v3.13+ +Cc: Ville Syrjälä +Cc: Lucas De Marchi +Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4800 +Signed-off-by: Jani Nikula +Reviewed-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/cc363f42d6b5a5932b6d218fefcc8bdfb15dbbe5.1644489329.git.jani.nikula@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/display/intel_opregion.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/drivers/gpu/drm/i915/display/intel_opregion.c ++++ b/drivers/gpu/drm/i915/display/intel_opregion.c +@@ -375,6 +375,21 @@ int intel_opregion_notify_encoder(struct + return -EINVAL; + } + ++ /* ++ * The port numbering and mapping here is bizarre. The now-obsolete ++ * swsci spec supports ports numbered [0..4]. Port E is handled as a ++ * special case, but port F and beyond are not. The functionality is ++ * supposed to be obsolete for new platforms. Just bail out if the port ++ * number is out of bounds after mapping. ++ */ ++ if (port > 4) { ++ drm_dbg_kms(&dev_priv->drm, ++ "[ENCODER:%d:%s] port %c (index %u) out of bounds for display power state notification\n", ++ intel_encoder->base.base.id, intel_encoder->base.name, ++ port_name(intel_encoder->port), port); ++ return -EINVAL; ++ } ++ + if (!enable) + parm |= 4 << 8; + diff --git a/queue-5.17/drm-nouveau-backlight-fix-lvds-backlight-detection-on-some-laptops.patch b/queue-5.17/drm-nouveau-backlight-fix-lvds-backlight-detection-on-some-laptops.patch new file mode 100644 index 00000000000..8664963590f --- /dev/null +++ b/queue-5.17/drm-nouveau-backlight-fix-lvds-backlight-detection-on-some-laptops.patch @@ -0,0 +1,41 @@ +From 6b0076540faffd47f5a899bf12f3528c4f0e726b Mon Sep 17 00:00:00 2001 +From: Lyude Paul +Date: Fri, 4 Feb 2022 13:05:04 -0500 +Subject: drm/nouveau/backlight: Fix LVDS backlight detection on some laptops + +From: Lyude Paul + +commit 6b0076540faffd47f5a899bf12f3528c4f0e726b upstream. + +It seems that some laptops will report having both an eDP and LVDS +connector, even though only the LVDS connector is actually hooked up. This +can lead to issues with backlight registration if the eDP connector ends up +getting registered before the LVDS connector, as the backlight device will +then be registered to the eDP connector instead of the LVDS connector. + +So, fix this by only registering the backlight on connectors that are +reported as being connected. + +Signed-off-by: Lyude Paul +Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau") +Bugzilla: https://gitlab.freedesktop.org/drm/nouveau/-/issues/137 +Cc: # v5.15+ +Reviewed-by: Karol Herbst +Link: https://patchwork.freedesktop.org/patch/msgid/20220204180504.328999-1-lyude@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/nouveau_backlight.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c ++++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c +@@ -294,7 +294,8 @@ nv50_backlight_init(struct nouveau_backl + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev); + struct nvif_object *device = &drm->client.device.object; + +- if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(ffs(nv_encoder->dcb->or) - 1))) ++ if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(ffs(nv_encoder->dcb->or) - 1)) || ++ nv_conn->base.status != connector_status_connected) + return -ENODEV; + + if (nv_conn->type == DCB_CONNECTOR_eDP) { diff --git a/queue-5.17/drm-nouveau-backlight-just-set-all-backlight-types-as-raw.patch b/queue-5.17/drm-nouveau-backlight-just-set-all-backlight-types-as-raw.patch new file mode 100644 index 00000000000..954f5ebd0b9 --- /dev/null +++ b/queue-5.17/drm-nouveau-backlight-just-set-all-backlight-types-as-raw.patch @@ -0,0 +1,58 @@ +From b21a142fd2055d8276169efcc95b624ff908a341 Mon Sep 17 00:00:00 2001 +From: Lyude Paul +Date: Fri, 4 Feb 2022 14:33:19 -0500 +Subject: drm/nouveau/backlight: Just set all backlight types as RAW + +From: Lyude Paul + +commit b21a142fd2055d8276169efcc95b624ff908a341 upstream. + +Currently we can get a warning on systems with eDP backlights like so: + + nv_backlight: invalid backlight type + WARNING: CPU: 4 PID: 454 at drivers/video/backlight/backlight.c:420 + backlight_device_register+0x226/0x250 + +This happens as a result of us not filling out props.type for the eDP +backlight, even though we do it for all other backlight types. + +Since nothing in our driver uses anything but BACKLIGHT_RAW, let's take the +props\.type assignments out of the codepaths for individual backlight types +and just set it unconditionally to prevent this from happening again. + +Signed-off-by: Lyude Paul +Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau") +Cc: # v5.15+ +Reviewed-by: Karol Herbst +Link: https://patchwork.freedesktop.org/patch/msgid/20220204193319.451119-1-lyude@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/nouveau_backlight.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c ++++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c +@@ -101,7 +101,6 @@ nv40_backlight_init(struct nouveau_encod + if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK)) + return -ENODEV; + +- props->type = BACKLIGHT_RAW; + props->max_brightness = 31; + *ops = &nv40_bl_ops; + return 0; +@@ -343,7 +342,6 @@ nv50_backlight_init(struct nouveau_backl + else + *ops = &nva3_bl_ops; + +- props->type = BACKLIGHT_RAW; + props->max_brightness = 100; + + return 0; +@@ -411,6 +409,7 @@ nouveau_backlight_init(struct drm_connec + goto fail_alloc; + } + ++ props.type = BACKLIGHT_RAW; + bl->dev = backlight_device_register(backlight_name, connector->kdev, + nv_encoder, ops, &props); + if (IS_ERR(bl->dev)) { diff --git a/queue-5.17/drm-syncobj-flatten-dma_fence_chains-on-transfer.patch b/queue-5.17/drm-syncobj-flatten-dma_fence_chains-on-transfer.patch new file mode 100644 index 00000000000..07b635bac4c --- /dev/null +++ b/queue-5.17/drm-syncobj-flatten-dma_fence_chains-on-transfer.patch @@ -0,0 +1,112 @@ +From 721255b52700b320c4ae2e23d57f7d9ad1db50b9 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20K=C3=B6nig?= +Date: Wed, 9 Feb 2022 19:13:04 +0100 +Subject: drm/syncobj: flatten dma_fence_chains on transfer +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Christian König + +commit 721255b52700b320c4ae2e23d57f7d9ad1db50b9 upstream. + +It is illegal to add a dma_fence_chain as timeline point. Flatten out +the fences into a dma_fence_array instead. + +Signed-off-by: Christian König +Reviewed-by: Nirmoy Das +Cc: +Link: https://patchwork.freedesktop.org/patch/msgid/20220209182600.434803-1-christian.koenig@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_syncobj.c | 61 ++++++++++++++++++++++++++++++++++++++---- + 1 file changed, 56 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/drm_syncobj.c ++++ b/drivers/gpu/drm/drm_syncobj.c +@@ -853,12 +853,57 @@ drm_syncobj_fd_to_handle_ioctl(struct dr + &args->handle); + } + ++ ++/* ++ * Try to flatten a dma_fence_chain into a dma_fence_array so that it can be ++ * added as timeline fence to a chain again. ++ */ ++static int drm_syncobj_flatten_chain(struct dma_fence **f) ++{ ++ struct dma_fence_chain *chain = to_dma_fence_chain(*f); ++ struct dma_fence *tmp, **fences; ++ struct dma_fence_array *array; ++ unsigned int count; ++ ++ if (!chain) ++ return 0; ++ ++ count = 0; ++ dma_fence_chain_for_each(tmp, &chain->base) ++ ++count; ++ ++ fences = kmalloc_array(count, sizeof(*fences), GFP_KERNEL); ++ if (!fences) ++ return -ENOMEM; ++ ++ count = 0; ++ dma_fence_chain_for_each(tmp, &chain->base) ++ fences[count++] = dma_fence_get(tmp); ++ ++ array = dma_fence_array_create(count, fences, ++ dma_fence_context_alloc(1), ++ 1, false); ++ if (!array) ++ goto free_fences; ++ ++ dma_fence_put(*f); ++ *f = &array->base; ++ return 0; ++ ++free_fences: ++ while (count--) ++ dma_fence_put(fences[count]); ++ ++ kfree(fences); ++ return -ENOMEM; ++} ++ + static int drm_syncobj_transfer_to_timeline(struct drm_file *file_private, + struct drm_syncobj_transfer *args) + { + struct drm_syncobj *timeline_syncobj = NULL; +- struct dma_fence *fence; + struct dma_fence_chain *chain; ++ struct dma_fence *fence; + int ret; + + timeline_syncobj = drm_syncobj_find(file_private, args->dst_handle); +@@ -869,16 +914,22 @@ static int drm_syncobj_transfer_to_timel + args->src_point, args->flags, + &fence); + if (ret) +- goto err; ++ goto err_put_timeline; ++ ++ ret = drm_syncobj_flatten_chain(&fence); ++ if (ret) ++ goto err_free_fence; ++ + chain = dma_fence_chain_alloc(); + if (!chain) { + ret = -ENOMEM; +- goto err1; ++ goto err_free_fence; + } ++ + drm_syncobj_add_point(timeline_syncobj, chain, fence, args->dst_point); +-err1: ++err_free_fence: + dma_fence_put(fence); +-err: ++err_put_timeline: + drm_syncobj_put(timeline_syncobj); + + return ret; diff --git a/queue-5.17/kvm-s390x-fix-sck-locking.patch b/queue-5.17/kvm-s390x-fix-sck-locking.patch new file mode 100644 index 00000000000..07835f5bf63 --- /dev/null +++ b/queue-5.17/kvm-s390x-fix-sck-locking.patch @@ -0,0 +1,126 @@ +From c0573ba5c5a2244dc02060b1f374d4593c1d20b7 Mon Sep 17 00:00:00 2001 +From: Claudio Imbrenda +Date: Tue, 1 Mar 2022 15:33:40 +0100 +Subject: KVM: s390x: fix SCK locking + +From: Claudio Imbrenda + +commit c0573ba5c5a2244dc02060b1f374d4593c1d20b7 upstream. + +When handling the SCK instruction, the kvm lock is taken, even though +the vcpu lock is already being held. The normal locking order is kvm +lock first and then vcpu lock. This is can (and in some circumstances +does) lead to deadlocks. + +The function kvm_s390_set_tod_clock is called both by the SCK handler +and by some IOCTLs to set the clock. The IOCTLs will not hold the vcpu +lock, so they can safely take the kvm lock. The SCK handler holds the +vcpu lock, but will also somehow need to acquire the kvm lock without +relinquishing the vcpu lock. + +The solution is to factor out the code to set the clock, and provide +two wrappers. One is called like the original function and does the +locking, the other is called kvm_s390_try_set_tod_clock and uses +trylock to try to acquire the kvm lock. This new wrapper is then used +in the SCK handler. If locking fails, -EAGAIN is returned, which is +eventually propagated to userspace, thus also freeing the vcpu lock and +allowing for forward progress. + +This is not the most efficient or elegant way to solve this issue, but +the SCK instruction is deprecated and its performance is not critical. + +The goal of this patch is just to provide a simple but correct way to +fix the bug. + +Fixes: 6a3f95a6b04c ("KVM: s390: Intercept SCK instruction") +Signed-off-by: Claudio Imbrenda +Reviewed-by: Christian Borntraeger +Reviewed-by: Janis Schoetterl-Glausch +Link: https://lore.kernel.org/r/20220301143340.111129-1-imbrenda@linux.ibm.com +Cc: stable@vger.kernel.org +Signed-off-by: Christian Borntraeger +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/kvm/kvm-s390.c | 19 ++++++++++++++++--- + arch/s390/kvm/kvm-s390.h | 4 ++-- + arch/s390/kvm/priv.c | 15 ++++++++++++++- + 3 files changed, 32 insertions(+), 6 deletions(-) + +--- a/arch/s390/kvm/kvm-s390.c ++++ b/arch/s390/kvm/kvm-s390.c +@@ -3869,14 +3869,12 @@ retry: + return 0; + } + +-void kvm_s390_set_tod_clock(struct kvm *kvm, +- const struct kvm_s390_vm_tod_clock *gtod) ++static void __kvm_s390_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod) + { + struct kvm_vcpu *vcpu; + union tod_clock clk; + unsigned long i; + +- mutex_lock(&kvm->lock); + preempt_disable(); + + store_tod_clock_ext(&clk); +@@ -3897,7 +3895,22 @@ void kvm_s390_set_tod_clock(struct kvm * + + kvm_s390_vcpu_unblock_all(kvm); + preempt_enable(); ++} ++ ++void kvm_s390_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod) ++{ ++ mutex_lock(&kvm->lock); ++ __kvm_s390_set_tod_clock(kvm, gtod); ++ mutex_unlock(&kvm->lock); ++} ++ ++int kvm_s390_try_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod) ++{ ++ if (!mutex_trylock(&kvm->lock)) ++ return 0; ++ __kvm_s390_set_tod_clock(kvm, gtod); + mutex_unlock(&kvm->lock); ++ return 1; + } + + /** +--- a/arch/s390/kvm/kvm-s390.h ++++ b/arch/s390/kvm/kvm-s390.h +@@ -349,8 +349,8 @@ int kvm_s390_handle_sigp(struct kvm_vcpu + int kvm_s390_handle_sigp_pei(struct kvm_vcpu *vcpu); + + /* implemented in kvm-s390.c */ +-void kvm_s390_set_tod_clock(struct kvm *kvm, +- const struct kvm_s390_vm_tod_clock *gtod); ++void kvm_s390_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod); ++int kvm_s390_try_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod); + long kvm_arch_fault_in_page(struct kvm_vcpu *vcpu, gpa_t gpa, int writable); + int kvm_s390_store_status_unloaded(struct kvm_vcpu *vcpu, unsigned long addr); + int kvm_s390_vcpu_store_status(struct kvm_vcpu *vcpu, unsigned long addr); +--- a/arch/s390/kvm/priv.c ++++ b/arch/s390/kvm/priv.c +@@ -102,7 +102,20 @@ static int handle_set_clock(struct kvm_v + return kvm_s390_inject_prog_cond(vcpu, rc); + + VCPU_EVENT(vcpu, 3, "SCK: setting guest TOD to 0x%llx", gtod.tod); +- kvm_s390_set_tod_clock(vcpu->kvm, >od); ++ /* ++ * To set the TOD clock the kvm lock must be taken, but the vcpu lock ++ * is already held in handle_set_clock. The usual lock order is the ++ * opposite. As SCK is deprecated and should not be used in several ++ * cases, for example when the multiple epoch facility or TOD clock ++ * steering facility is installed (see Principles of Operation), a ++ * slow path can be used. If the lock can not be taken via try_lock, ++ * the instruction will be retried via -EAGAIN at a later point in ++ * time. ++ */ ++ if (!kvm_s390_try_set_tod_clock(vcpu->kvm, >od)) { ++ kvm_s390_retry_instr(vcpu); ++ return -EAGAIN; ++ } + + kvm_s390_set_psw_cc(vcpu, 0); + return 0; diff --git a/queue-5.17/mips-always-permit-to-build-u-boot-images.patch b/queue-5.17/mips-always-permit-to-build-u-boot-images.patch new file mode 100644 index 00000000000..ef4ae539af3 --- /dev/null +++ b/queue-5.17/mips-always-permit-to-build-u-boot-images.patch @@ -0,0 +1,53 @@ +From 34275ac292ae141ebc1296b72f005f71b25998a7 Mon Sep 17 00:00:00 2001 +From: Paul Cercueil +Date: Sun, 6 Mar 2022 15:16:48 +0000 +Subject: mips: Always permit to build u-boot images + +From: Paul Cercueil + +commit 34275ac292ae141ebc1296b72f005f71b25998a7 upstream. + +The platforms where the kernel should be loaded above 0x8000.0000 do not +support loading u-boot images, that doesn't mean that we shouldn't be +able to generate them. + +Additionally, since commit 79876cc1d7b8 ("MIPS: new Kconfig option +ZBOOT_LOAD_ADDRESS"), the $(zload-y) variable was no longer hardcoded, +which made it impossible to use the uzImage.bin target. + +Fixes: 79876cc1d7b8 ("MIPS: new Kconfig option ZBOOT_LOAD_ADDRESS") +Cc: +Signed-off-by: Paul Cercueil +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/Makefile | 4 ---- + 1 file changed, 4 deletions(-) + +--- a/arch/mips/Makefile ++++ b/arch/mips/Makefile +@@ -340,14 +340,12 @@ drivers-$(CONFIG_PM) += arch/mips/power/ + boot-y := vmlinux.bin + boot-y += vmlinux.ecoff + boot-y += vmlinux.srec +-ifeq ($(shell expr $(load-y) \< 0xffffffff80000000 2> /dev/null), 0) + boot-y += uImage + boot-y += uImage.bin + boot-y += uImage.bz2 + boot-y += uImage.gz + boot-y += uImage.lzma + boot-y += uImage.lzo +-endif + boot-y += vmlinux.itb + boot-y += vmlinux.gz.itb + boot-y += vmlinux.bz2.itb +@@ -359,9 +357,7 @@ bootz-y := vmlinuz + bootz-y += vmlinuz.bin + bootz-y += vmlinuz.ecoff + bootz-y += vmlinuz.srec +-ifeq ($(shell expr $(zload-y) \< 0xffffffff80000000 2> /dev/null), 0) + bootz-y += uzImage.bin +-endif + bootz-y += vmlinuz.itb + + # diff --git a/queue-5.17/pci-imx6-allow-to-probe-when-dw_pcie_wait_for_link-fails.patch b/queue-5.17/pci-imx6-allow-to-probe-when-dw_pcie_wait_for_link-fails.patch new file mode 100644 index 00000000000..f0cb962092b --- /dev/null +++ b/queue-5.17/pci-imx6-allow-to-probe-when-dw_pcie_wait_for_link-fails.patch @@ -0,0 +1,80 @@ +From f81f095e87715e198471f4653952fe5e3f824874 Mon Sep 17 00:00:00 2001 +From: Fabio Estevam +Date: Thu, 6 Jan 2022 07:36:45 -0300 +Subject: PCI: imx6: Allow to probe when dw_pcie_wait_for_link() fails + +From: Fabio Estevam + +commit f81f095e87715e198471f4653952fe5e3f824874 upstream. + +The intention of commit 886a9c134755 ("PCI: dwc: Move link handling into +common code") was to standardize the behavior of link down as explained +in its commit log: + +"The behavior for a link down was inconsistent as some drivers would fail +probe in that case while others succeed. Let's standardize this to +succeed as there are usecases where devices (and the link) appear later +even without hotplug. For example, a reconfigured FPGA device." + +The pci-imx6 still fails to probe when the link is not present, which +causes the following warning: + +imx6q-pcie 8ffc000.pcie: Phy link never came up +imx6q-pcie: probe of 8ffc000.pcie failed with error -110 +------------[ cut here ]------------ +WARNING: CPU: 0 PID: 30 at drivers/regulator/core.c:2257 _regulator_put.part.0+0x1b8/0x1dc +Modules linked in: +CPU: 0 PID: 30 Comm: kworker/u2:2 Not tainted 5.15.0-next-20211103 #1 +Hardware name: Freescale i.MX6 SoloX (Device Tree) +Workqueue: events_unbound async_run_entry_fn +[] (unwind_backtrace) from [] (show_stack+0x10/0x14) +[] (show_stack) from [] (dump_stack_lvl+0x58/0x70) +[] (dump_stack_lvl) from [] (__warn+0xd4/0x154) +[] (__warn) from [] (warn_slowpath_fmt+0x74/0xa8) +[] (warn_slowpath_fmt) from [] (_regulator_put.part.0+0x1b8/0x1dc) +[] (_regulator_put.part.0) from [] (regulator_put+0x2c/0x3c) +[] (regulator_put) from [] (release_nodes+0x50/0x178) + +Fix this problem by ignoring the dw_pcie_wait_for_link() error like +it is done on the other dwc drivers. + +Tested on imx6sx-sdb and imx6q-sabresd boards. + +Link: https://lore.kernel.org/r/20220106103645.2790803-1-festevam@gmail.com +Fixes: 886a9c134755 ("PCI: dwc: Move link handling into common code") +Signed-off-by: Fabio Estevam +Signed-off-by: Lorenzo Pieralisi +Reviewed-by: Rob Herring +Reviewed-by: Richard Zhu +Cc: +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/dwc/pci-imx6.c | 10 ++-------- + 1 file changed, 2 insertions(+), 8 deletions(-) + +--- a/drivers/pci/controller/dwc/pci-imx6.c ++++ b/drivers/pci/controller/dwc/pci-imx6.c +@@ -809,9 +809,7 @@ static int imx6_pcie_start_link(struct d + /* Start LTSSM. */ + imx6_pcie_ltssm_enable(dev); + +- ret = dw_pcie_wait_for_link(pci); +- if (ret) +- goto err_reset_phy; ++ dw_pcie_wait_for_link(pci); + + if (pci->link_gen == 2) { + /* Allow Gen2 mode after the link is up. */ +@@ -847,11 +845,7 @@ static int imx6_pcie_start_link(struct d + } + + /* Make sure link training is finished as well! */ +- ret = dw_pcie_wait_for_link(pci); +- if (ret) { +- dev_err(dev, "Failed to bring link up!\n"); +- goto err_reset_phy; +- } ++ dw_pcie_wait_for_link(pci); + } else { + dev_info(dev, "Link: Gen2 disabled\n"); + } diff --git a/queue-5.17/pci-pciehp-clear-cmd_busy-bit-in-polling-mode.patch b/queue-5.17/pci-pciehp-clear-cmd_busy-bit-in-polling-mode.patch new file mode 100644 index 00000000000..0b559c27153 --- /dev/null +++ b/queue-5.17/pci-pciehp-clear-cmd_busy-bit-in-polling-mode.patch @@ -0,0 +1,53 @@ +From 92912b175178c7e895f5e5e9f1e30ac30319162b Mon Sep 17 00:00:00 2001 +From: Liguang Zhang +Date: Thu, 11 Nov 2021 13:42:58 +0800 +Subject: PCI: pciehp: Clear cmd_busy bit in polling mode + +From: Liguang Zhang + +commit 92912b175178c7e895f5e5e9f1e30ac30319162b upstream. + +Writes to a Downstream Port's Slot Control register are PCIe hotplug +"commands." If the Port supports Command Completed events, software must +wait for a command to complete before writing to Slot Control again. + +pcie_do_write_cmd() sets ctrl->cmd_busy when it writes to Slot Control. If +software notification is enabled, i.e., PCI_EXP_SLTCTL_HPIE and +PCI_EXP_SLTCTL_CCIE are set, ctrl->cmd_busy is cleared by pciehp_isr(). + +But when software notification is disabled, as it is when pcie_init() +powers off an empty slot, pcie_wait_cmd() uses pcie_poll_cmd() to poll for +command completion, and it neglects to clear ctrl->cmd_busy, which leads to +spurious timeouts: + + pcieport 0000:00:03.0: pciehp: Timeout on hotplug command 0x01c0 (issued 2264 msec ago) + pcieport 0000:00:03.0: pciehp: Timeout on hotplug command 0x05c0 (issued 2288 msec ago) + +Clear ctrl->cmd_busy in pcie_poll_cmd() when it detects a Command Completed +event (PCI_EXP_SLTSTA_CC). + +[bhelgaas: commit log] +Fixes: a5dd4b4b0570 ("PCI: pciehp: Wait for hotplug command completion where necessary") +Link: https://lore.kernel.org/r/20211111054258.7309-1-zhangliguang@linux.alibaba.com +Link: https://bugzilla.kernel.org/show_bug.cgi?id=215143 +Link: https://lore.kernel.org/r/20211126173309.GA12255@wunner.de +Signed-off-by: Liguang Zhang +Signed-off-by: Bjorn Helgaas +Reviewed-by: Lukas Wunner +Cc: stable@vger.kernel.org # v4.19+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/hotplug/pciehp_hpc.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/pci/hotplug/pciehp_hpc.c ++++ b/drivers/pci/hotplug/pciehp_hpc.c +@@ -98,6 +98,8 @@ static int pcie_poll_cmd(struct controll + if (slot_status & PCI_EXP_SLTSTA_CC) { + pcie_capability_write_word(pdev, PCI_EXP_SLTSTA, + PCI_EXP_SLTSTA_CC); ++ ctrl->cmd_busy = 0; ++ smp_mb(); + return 1; + } + msleep(10); diff --git a/queue-5.17/pci-xgene-revert-pci-xgene-fix-ib-window-setup.patch b/queue-5.17/pci-xgene-revert-pci-xgene-fix-ib-window-setup.patch new file mode 100644 index 00000000000..3193ba18ea1 --- /dev/null +++ b/queue-5.17/pci-xgene-revert-pci-xgene-fix-ib-window-setup.patch @@ -0,0 +1,49 @@ +From 825da4e9cec68713fbb02dc6f71fe1bf65fe8050 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Mon, 21 Mar 2022 10:48:43 +0000 +Subject: PCI: xgene: Revert "PCI: xgene: Fix IB window setup" +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marc Zyngier + +commit 825da4e9cec68713fbb02dc6f71fe1bf65fe8050 upstream. + +Commit c7a75d07827a ("PCI: xgene: Fix IB window setup") tried to +fix the damages that 6dce5aa59e0b ("PCI: xgene: Use inbound resources +for setup") caused, but actually didn't improve anything for some +plarforms (at least Mustang and m400 are still broken). + +Given that 6dce5aa59e0b has been reverted, revert this patch as well, +restoring the PCIe support on XGene to its pre-5.5, working state. + +Link: https://lore.kernel.org/r/YjN8pT5e6/8cRohQ@xps13.dannf +Link: https://lore.kernel.org/r/20220321104843.949645-3-maz@kernel.org +Fixes: c7a75d07827a ("PCI: xgene: Fix IB window setup") +Signed-off-by: Marc Zyngier +Signed-off-by: Lorenzo Pieralisi +Cc: stable@vger.kernel.org +Cc: Rob Herring +Cc: Toan Le +Cc: Lorenzo Pieralisi +Cc: Krzysztof Wilczyński +Cc: Bjorn Helgaas +Cc: Stéphane Graber +Cc: dann frazier +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/pci-xgene.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/pci/controller/pci-xgene.c ++++ b/drivers/pci/controller/pci-xgene.c +@@ -465,7 +465,7 @@ static int xgene_pcie_select_ib_reg(u8 * + return 1; + } + +- if ((size > SZ_1K) && (size < SZ_4G) && !(*ib_reg_mask & (1 << 0))) { ++ if ((size > SZ_1K) && (size < SZ_1T) && !(*ib_reg_mask & (1 << 0))) { + *ib_reg_mask |= (1 << 0); + return 0; + } diff --git a/queue-5.17/pci-xgene-revert-pci-xgene-use-inbound-resources-for-setup.patch b/queue-5.17/pci-xgene-revert-pci-xgene-use-inbound-resources-for-setup.patch new file mode 100644 index 00000000000..3d168db5e94 --- /dev/null +++ b/queue-5.17/pci-xgene-revert-pci-xgene-use-inbound-resources-for-setup.patch @@ -0,0 +1,108 @@ +From 1874b6d7ab1bdc900e8398026350313ac29caddb Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Mon, 21 Mar 2022 10:48:42 +0000 +Subject: PCI: xgene: Revert "PCI: xgene: Use inbound resources for setup" +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marc Zyngier + +commit 1874b6d7ab1bdc900e8398026350313ac29caddb upstream. + +Commit 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") +killed PCIe on my XGene-1 box (a Mustang board). The machine itself +is still alive, but half of its storage (over NVMe) is gone, and the +NVMe driver just times out. + +Note that this machine boots with a device tree provided by the +UEFI firmware (2016 vintage), which could well be non conformant +with the spec, hence the breakage. + +With the patch reverted, the box boots 5.17-rc8 with flying colors. + +Link: https://lore.kernel.org/all/Yf2wTLjmcRj+AbDv@xps13.dannf +Link: https://lore.kernel.org/r/20220321104843.949645-2-maz@kernel.org +Fixes: 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") +Signed-off-by: Marc Zyngier +Signed-off-by: Lorenzo Pieralisi +Cc: stable@vger.kernel.org +Cc: Rob Herring +Cc: Toan Le +Cc: Lorenzo Pieralisi +Cc: Krzysztof Wilczyński +Cc: Bjorn Helgaas +Cc: Stéphane Graber +Cc: dann frazier +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/pci-xgene.c | 33 ++++++++++++++++++++++----------- + 1 file changed, 22 insertions(+), 11 deletions(-) + +--- a/drivers/pci/controller/pci-xgene.c ++++ b/drivers/pci/controller/pci-xgene.c +@@ -479,28 +479,27 @@ static int xgene_pcie_select_ib_reg(u8 * + } + + static void xgene_pcie_setup_ib_reg(struct xgene_pcie *port, +- struct resource_entry *entry, +- u8 *ib_reg_mask) ++ struct of_pci_range *range, u8 *ib_reg_mask) + { + void __iomem *cfg_base = port->cfg_base; + struct device *dev = port->dev; + void __iomem *bar_addr; + u32 pim_reg; +- u64 cpu_addr = entry->res->start; +- u64 pci_addr = cpu_addr - entry->offset; +- u64 size = resource_size(entry->res); ++ u64 cpu_addr = range->cpu_addr; ++ u64 pci_addr = range->pci_addr; ++ u64 size = range->size; + u64 mask = ~(size - 1) | EN_REG; + u32 flags = PCI_BASE_ADDRESS_MEM_TYPE_64; + u32 bar_low; + int region; + +- region = xgene_pcie_select_ib_reg(ib_reg_mask, size); ++ region = xgene_pcie_select_ib_reg(ib_reg_mask, range->size); + if (region < 0) { + dev_warn(dev, "invalid pcie dma-range config\n"); + return; + } + +- if (entry->res->flags & IORESOURCE_PREFETCH) ++ if (range->flags & IORESOURCE_PREFETCH) + flags |= PCI_BASE_ADDRESS_MEM_PREFETCH; + + bar_low = pcie_bar_low_val((u32)cpu_addr, flags); +@@ -531,13 +530,25 @@ static void xgene_pcie_setup_ib_reg(stru + + static int xgene_pcie_parse_map_dma_ranges(struct xgene_pcie *port) + { +- struct pci_host_bridge *bridge = pci_host_bridge_from_priv(port); +- struct resource_entry *entry; ++ struct device_node *np = port->node; ++ struct of_pci_range range; ++ struct of_pci_range_parser parser; ++ struct device *dev = port->dev; + u8 ib_reg_mask = 0; + +- resource_list_for_each_entry(entry, &bridge->dma_ranges) +- xgene_pcie_setup_ib_reg(port, entry, &ib_reg_mask); ++ if (of_pci_dma_range_parser_init(&parser, np)) { ++ dev_err(dev, "missing dma-ranges property\n"); ++ return -EINVAL; ++ } + ++ /* Get the dma-ranges from DT */ ++ for_each_of_pci_range(&parser, &range) { ++ u64 end = range.cpu_addr + range.size - 1; ++ ++ dev_dbg(dev, "0x%08x 0x%016llx..0x%016llx -> 0x%016llx\n", ++ range.flags, range.cpu_addr, end, range.pci_addr); ++ xgene_pcie_setup_ib_reg(port, &range, &ib_reg_mask); ++ } + return 0; + } + diff --git a/queue-5.17/series b/queue-5.17/series index f8a4ba07386..a6a02d3669d 100644 --- a/queue-5.17/series +++ b/queue-5.17/series @@ -173,3 +173,26 @@ media-venus-venc-fix-h264-8x8-transform-control.patch media-davinci-vpif-fix-unbalanced-runtime-pm-get.patch media-davinci-vpif-fix-unbalanced-runtime-pm-enable.patch media-davinci-vpif-fix-use-after-free-on-driver-unbind.patch +mips-always-permit-to-build-u-boot-images.patch +btrfs-zoned-mark-relocation-as-writing.patch +btrfs-extend-locking-to-all-space_info-members-accesses.patch +btrfs-verify-the-tranisd-of-the-to-be-written-dirty-extent-buffer.patch +xtensa-define-update_mmu_tlb-function.patch +xtensa-fix-stop_machine_cpuslocked-call-in-patch_text.patch +xtensa-fix-xtensa_wsr-always-writing-0.patch +kvm-s390x-fix-sck-locking.patch +drm-syncobj-flatten-dma_fence_chains-on-transfer.patch +drm-nouveau-backlight-fix-lvds-backlight-detection-on-some-laptops.patch +drm-nouveau-backlight-just-set-all-backlight-types-as-raw.patch +drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch +brcmfmac-firmware-allocate-space-for-default-boardrev-in-nvram.patch +brcmfmac-pcie-release-firmwares-in-the-brcmf_pcie_setup-error-path.patch +brcmfmac-pcie-declare-missing-firmware-files-in-pcie.c.patch +brcmfmac-pcie-replace-brcmf_pcie_copy_mem_todev-with-memcpy_toio.patch +brcmfmac-pcie-fix-crashes-due-to-early-irqs.patch +drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch +drm-i915-gem-add-missing-boundary-check-in-vm_access.patch +pci-imx6-allow-to-probe-when-dw_pcie_wait_for_link-fails.patch +pci-pciehp-clear-cmd_busy-bit-in-polling-mode.patch +pci-xgene-revert-pci-xgene-use-inbound-resources-for-setup.patch +pci-xgene-revert-pci-xgene-fix-ib-window-setup.patch diff --git a/queue-5.17/xtensa-define-update_mmu_tlb-function.patch b/queue-5.17/xtensa-define-update_mmu_tlb-function.patch new file mode 100644 index 00000000000..94624a9046e --- /dev/null +++ b/queue-5.17/xtensa-define-update_mmu_tlb-function.patch @@ -0,0 +1,56 @@ +From 1c4664faa38923330d478f046dc743a00c1e2dec Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Mon, 3 Jan 2022 12:08:31 -0800 +Subject: xtensa: define update_mmu_tlb function + +From: Max Filippov + +commit 1c4664faa38923330d478f046dc743a00c1e2dec upstream. + +Before the commit f9ce0be71d1f ("mm: Cleanup faultaround and finish_fault() +codepaths") there was a call to update_mmu_cache in alloc_set_pte that +used to invalidate TLB entry caching invalid PTE that caused a page +fault. That commit removed that call so now invalid TLB entry survives +causing repetitive page faults on the CPU that took the initial fault +until that TLB entry is occasionally evicted. This issue is spotted by +the xtensa TLB sanity checker. + +Fix this issue by defining update_mmu_tlb function that flushes TLB entry +for the faulting address. + +Cc: stable@vger.kernel.org # 5.12+ +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman +--- + arch/xtensa/include/asm/pgtable.h | 4 ++++ + arch/xtensa/mm/tlb.c | 6 ++++++ + 2 files changed, 10 insertions(+) + +--- a/arch/xtensa/include/asm/pgtable.h ++++ b/arch/xtensa/include/asm/pgtable.h +@@ -411,6 +411,10 @@ extern void update_mmu_cache(struct vm_ + + typedef pte_t *pte_addr_t; + ++void update_mmu_tlb(struct vm_area_struct *vma, ++ unsigned long address, pte_t *ptep); ++#define __HAVE_ARCH_UPDATE_MMU_TLB ++ + #endif /* !defined (__ASSEMBLY__) */ + + #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG +--- a/arch/xtensa/mm/tlb.c ++++ b/arch/xtensa/mm/tlb.c +@@ -162,6 +162,12 @@ void local_flush_tlb_kernel_range(unsign + } + } + ++void update_mmu_tlb(struct vm_area_struct *vma, ++ unsigned long address, pte_t *ptep) ++{ ++ local_flush_tlb_page(vma, address); ++} ++ + #ifdef CONFIG_DEBUG_TLB_SANITY + + static unsigned get_pte_for_vaddr(unsigned vaddr) diff --git a/queue-5.17/xtensa-fix-stop_machine_cpuslocked-call-in-patch_text.patch b/queue-5.17/xtensa-fix-stop_machine_cpuslocked-call-in-patch_text.patch new file mode 100644 index 00000000000..2d5b713dea2 --- /dev/null +++ b/queue-5.17/xtensa-fix-stop_machine_cpuslocked-call-in-patch_text.patch @@ -0,0 +1,34 @@ +From f406f2d03e07afc199dd8cf501f361dde6be8a69 Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Wed, 16 Mar 2022 02:04:17 -0700 +Subject: xtensa: fix stop_machine_cpuslocked call in patch_text + +From: Max Filippov + +commit f406f2d03e07afc199dd8cf501f361dde6be8a69 upstream. + +patch_text must invoke patch_text_stop_machine on all online CPUs, but +it calls stop_machine_cpuslocked with NULL cpumask. As a result only one +CPU runs patch_text_stop_machine potentially leaving stale icache +entries on other CPUs. Fix that by calling stop_machine_cpuslocked with +cpu_online_mask as the last argument. + +Cc: stable@vger.kernel.org +Fixes: 64711f9a47d4 ("xtensa: implement jump_label support") +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman +--- + arch/xtensa/kernel/jump_label.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/xtensa/kernel/jump_label.c ++++ b/arch/xtensa/kernel/jump_label.c +@@ -61,7 +61,7 @@ static void patch_text(unsigned long add + .data = data, + }; + stop_machine_cpuslocked(patch_text_stop_machine, +- &patch, NULL); ++ &patch, cpu_online_mask); + } else { + unsigned long flags; + diff --git a/queue-5.17/xtensa-fix-xtensa_wsr-always-writing-0.patch b/queue-5.17/xtensa-fix-xtensa_wsr-always-writing-0.patch new file mode 100644 index 00000000000..57f0db7c63b --- /dev/null +++ b/queue-5.17/xtensa-fix-xtensa_wsr-always-writing-0.patch @@ -0,0 +1,38 @@ +From a3d0245c58f962ee99d4440ea0eaf45fb7f5a5cc Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Sun, 20 Mar 2022 09:40:14 -0700 +Subject: xtensa: fix xtensa_wsr always writing 0 + +From: Max Filippov + +commit a3d0245c58f962ee99d4440ea0eaf45fb7f5a5cc upstream. + +The commit cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr") +replaced 'WSR' macro in the function xtensa_wsr with 'xtensa_set_sr', +but variable 'v' in the xtensa_set_sr body shadowed the argument 'v' +passed to it, resulting in wrong value written to debug registers. + +Fix that by removing intermediate variable from the xtensa_set_sr +macro body. + +Cc: stable@vger.kernel.org +Fixes: cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr") +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman +--- + arch/xtensa/include/asm/processor.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/xtensa/include/asm/processor.h ++++ b/arch/xtensa/include/asm/processor.h +@@ -246,8 +246,8 @@ extern unsigned long __get_wchan(struct + + #define xtensa_set_sr(x, sr) \ + ({ \ +- unsigned int v = (unsigned int)(x); \ +- __asm__ __volatile__ ("wsr %0, "__stringify(sr) :: "a"(v)); \ ++ __asm__ __volatile__ ("wsr %0, "__stringify(sr) :: \ ++ "a"((unsigned int)(x))); \ + }) + + #define xtensa_get_sr(sr) \