From: Greg Kroah-Hartman Date: Thu, 13 Jun 2024 07:21:39 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v4.19.316~75 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=884f8f7dd95fa59a9aacdd44601de5cd54a92229;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: 9p-add-missing-locking-around-taking-dentry-fid-list.patch clk-bcm-dvp-assign-num-before-accessing-hws.patch clk-bcm-rpi-assign-num-before-accessing-hws.patch clk-qcom-clk-alpha-pll-fix-rate-setting-for-stromer-plls.patch crypto-ecdsa-fix-module-auto-load-on-add-key.patch crypto-ecrdsa-fix-module-auto-load-on-add_key.patch crypto-qat-fix-adf_dev_reset_sync-memory-leak.patch drm-amd-fix-shutdown-again-on-some-smu-v13.0.4-11-platforms.patch kbuild-remove-support-for-clang-s-thinlto-caching.patch kvm-arm64-aarch32-fix-spurious-trapping-of-conditional-instructions.patch kvm-arm64-allow-aarch32-pstate.m-to-be-restored-as-system-mode.patch kvm-arm64-fix-aarch32-register-narrowing-on-userspace-write.patch kvm-svm-warn-on-vnmi-nmi-window-iff-nmis-are-outright-masked.patch loongarch-add-all-cpus-enabled-by-fdt-to-numa-node-0.patch loongarch-override-higher-address-bits-in-jump_virt_addr.patch mm-fix-race-between-__split_huge_pmd_locked-and-gup-fast.patch revert-drm-amdkfd-fix-gfx_target_version-for-certain-11.0.3-devices.patch --- diff --git a/queue-6.6/9p-add-missing-locking-around-taking-dentry-fid-list.patch b/queue-6.6/9p-add-missing-locking-around-taking-dentry-fid-list.patch new file mode 100644 index 00000000000..693c0950652 --- /dev/null +++ b/queue-6.6/9p-add-missing-locking-around-taking-dentry-fid-list.patch @@ -0,0 +1,70 @@ +From c898afdc15645efb555acb6d85b484eb40a45409 Mon Sep 17 00:00:00 2001 +From: Dominique Martinet +Date: Tue, 21 May 2024 21:13:36 +0900 +Subject: 9p: add missing locking around taking dentry fid list + +From: Dominique Martinet + +commit c898afdc15645efb555acb6d85b484eb40a45409 upstream. + +Fix a use-after-free on dentry's d_fsdata fid list when a thread +looks up a fid through dentry while another thread unlinks it: + +UAF thread: +refcount_t: addition on 0; use-after-free. + p9_fid_get linux/./include/net/9p/client.h:262 + v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 + v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 + v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314 + v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 + vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 + +Freed by: + p9_fid_destroy (inlined) + p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456 + p9_fid_put linux/./include/net/9p/client.h:278 + v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 + v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 + vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 + +The problem is that d_fsdata was not accessed under d_lock, because +d_release() normally is only called once the dentry is otherwise no +longer accessible but since we also call it explicitly in v9fs_remove +that lock is required: +move the hlist out of the dentry under lock then unref its fids once +they are no longer accessible. + +Fixes: 154372e67d40 ("fs/9p: fix create-unlink-getattr idiom") +Cc: stable@vger.kernel.org +Reported-by: Meysam Firouzi +Reported-by: Amirmohammad Eftekhar +Reviewed-by: Christian Schoenebeck +Message-ID: <20240521122947.1080227-1-asmadeus@codewreck.org> +Signed-off-by: Dominique Martinet +Signed-off-by: Greg Kroah-Hartman +--- + fs/9p/vfs_dentry.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/fs/9p/vfs_dentry.c ++++ b/fs/9p/vfs_dentry.c +@@ -48,12 +48,17 @@ static int v9fs_cached_dentry_delete(con + static void v9fs_dentry_release(struct dentry *dentry) + { + struct hlist_node *p, *n; ++ struct hlist_head head; + + p9_debug(P9_DEBUG_VFS, " dentry: %pd (%p)\n", + dentry, dentry); +- hlist_for_each_safe(p, n, (struct hlist_head *)&dentry->d_fsdata) ++ ++ spin_lock(&dentry->d_lock); ++ hlist_move_list((struct hlist_head *)&dentry->d_fsdata, &head); ++ spin_unlock(&dentry->d_lock); ++ ++ hlist_for_each_safe(p, n, &head) + p9_fid_put(hlist_entry(p, struct p9_fid, dlist)); +- dentry->d_fsdata = NULL; + } + + static int v9fs_lookup_revalidate(struct dentry *dentry, unsigned int flags) diff --git a/queue-6.6/clk-bcm-dvp-assign-num-before-accessing-hws.patch b/queue-6.6/clk-bcm-dvp-assign-num-before-accessing-hws.patch new file mode 100644 index 00000000000..9163f442470 --- /dev/null +++ b/queue-6.6/clk-bcm-dvp-assign-num-before-accessing-hws.patch @@ -0,0 +1,62 @@ +From 9368cdf90f52a68120d039887ccff74ff33b4444 Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Thu, 25 Apr 2024 09:55:51 -0700 +Subject: clk: bcm: dvp: Assign ->num before accessing ->hws + +From: Nathan Chancellor + +commit 9368cdf90f52a68120d039887ccff74ff33b4444 upstream. + +Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with +__counted_by") annotated the hws member of 'struct clk_hw_onecell_data' +with __counted_by, which informs the bounds sanitizer about the number +of elements in hws, so that it can warn when hws is accessed out of +bounds. As noted in that change, the __counted_by member must be +initialized with the number of elements before the first array access +happens, otherwise there will be a warning from each access prior to the +initialization because the number of elements is zero. This occurs in +clk_dvp_probe() due to ->num being assigned after ->hws has been +accessed: + + UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2 + index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') + +Move the ->num initialization to before the first access of ->hws, which +clears up the warning. + +Cc: stable@vger.kernel.org +Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") +Signed-off-by: Nathan Chancellor +Link: https://lore.kernel.org/r/20240425-cbl-bcm-assign-counted-by-val-before-access-v1-1-e2db3b82d5ef@kernel.org +Reviewed-by: Kees Cook +Reviewed-by: Florian Fainelli +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/bcm/clk-bcm2711-dvp.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/clk/bcm/clk-bcm2711-dvp.c b/drivers/clk/bcm/clk-bcm2711-dvp.c +index e4fbbf3c40fe..3cb235df9d37 100644 +--- a/drivers/clk/bcm/clk-bcm2711-dvp.c ++++ b/drivers/clk/bcm/clk-bcm2711-dvp.c +@@ -56,6 +56,8 @@ static int clk_dvp_probe(struct platform_device *pdev) + if (ret) + return ret; + ++ data->num = NR_CLOCKS; ++ + data->hws[0] = clk_hw_register_gate_parent_data(&pdev->dev, + "hdmi0-108MHz", + &clk_dvp_parent, 0, +@@ -76,7 +78,6 @@ static int clk_dvp_probe(struct platform_device *pdev) + goto unregister_clk0; + } + +- data->num = NR_CLOCKS; + ret = of_clk_add_hw_provider(pdev->dev.of_node, of_clk_hw_onecell_get, + data); + if (ret) +-- +2.45.2 + diff --git a/queue-6.6/clk-bcm-rpi-assign-num-before-accessing-hws.patch b/queue-6.6/clk-bcm-rpi-assign-num-before-accessing-hws.patch new file mode 100644 index 00000000000..100aca28967 --- /dev/null +++ b/queue-6.6/clk-bcm-rpi-assign-num-before-accessing-hws.patch @@ -0,0 +1,55 @@ +From 6dc445c1905096b2ed4db1a84570375b4e00cc0f Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Thu, 25 Apr 2024 09:55:52 -0700 +Subject: clk: bcm: rpi: Assign ->num before accessing ->hws + +From: Nathan Chancellor + +commit 6dc445c1905096b2ed4db1a84570375b4e00cc0f upstream. + +Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with +__counted_by") annotated the hws member of 'struct clk_hw_onecell_data' +with __counted_by, which informs the bounds sanitizer about the number +of elements in hws, so that it can warn when hws is accessed out of +bounds. As noted in that change, the __counted_by member must be +initialized with the number of elements before the first array access +happens, otherwise there will be a warning from each access prior to the +initialization because the number of elements is zero. This occurs in +raspberrypi_discover_clocks() due to ->num being assigned after ->hws +has been accessed: + + UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4 + index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') + +Move the ->num initialization to before the first access of ->hws, which +clears up the warning. + +Cc: stable@vger.kernel.org +Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") +Signed-off-by: Nathan Chancellor +Link: https://lore.kernel.org/r/20240425-cbl-bcm-assign-counted-by-val-before-access-v1-2-e2db3b82d5ef@kernel.org +Reviewed-by: Kees Cook +Reviewed-by: Florian Fainelli +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/bcm/clk-raspberrypi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c +index 829406dc44a2..4d411408e4af 100644 +--- a/drivers/clk/bcm/clk-raspberrypi.c ++++ b/drivers/clk/bcm/clk-raspberrypi.c +@@ -371,8 +371,8 @@ static int raspberrypi_discover_clocks(struct raspberrypi_clk *rpi, + if (IS_ERR(hw)) + return PTR_ERR(hw); + +- data->hws[clks->id] = hw; + data->num = clks->id + 1; ++ data->hws[clks->id] = hw; + } + + clks++; +-- +2.45.2 + diff --git a/queue-6.6/clk-qcom-clk-alpha-pll-fix-rate-setting-for-stromer-plls.patch b/queue-6.6/clk-qcom-clk-alpha-pll-fix-rate-setting-for-stromer-plls.patch new file mode 100644 index 00000000000..b2381216d0b --- /dev/null +++ b/queue-6.6/clk-qcom-clk-alpha-pll-fix-rate-setting-for-stromer-plls.patch @@ -0,0 +1,60 @@ +From 3c5b3e17b8fd1f1add5a9477306c355fab126977 Mon Sep 17 00:00:00 2001 +From: Gabor Juhos +Date: Thu, 28 Mar 2024 08:54:31 +0100 +Subject: clk: qcom: clk-alpha-pll: fix rate setting for Stromer PLLs + +From: Gabor Juhos + +commit 3c5b3e17b8fd1f1add5a9477306c355fab126977 upstream. + +The clk_alpha_pll_stromer_set_rate() function writes inproper +values into the ALPHA_VAL{,_U} registers which results in wrong +clock rates when the alpha value is used. + +The broken behaviour can be seen on IPQ5018 for example, when +dynamic scaling sets the CPU frequency to 800000 KHz. In this +case the CPU cores are running only at 792031 KHz: + + # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq + 800000 + # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq + 792031 + +This happens because the function ignores the fact that the alpha +value calculated by the alpha_pll_round_rate() function is only +32 bits wide which must be extended to 40 bits if it is used on +a hardware which supports 40 bits wide values. + +Extend the clk_alpha_pll_stromer_set_rate() function to convert +the alpha value to 40 bits before wrinting that into the registers +in order to ensure that the hardware really uses the requested rate. + +After the change the CPU frequency is correct: + + # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq + 800000 + # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq + 800000 + +Cc: stable@vger.kernel.org +Fixes: e47a4f55f240 ("clk: qcom: clk-alpha-pll: Add support for Stromer PLLs") +Reviewed-by: Dmitry Baryshkov +Signed-off-by: Gabor Juhos +Link: https://lore.kernel.org/r/20240328-alpha-pll-fix-stromer-set-rate-v3-1-1b79714c78bc@gmail.com +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/qcom/clk-alpha-pll.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/clk/qcom/clk-alpha-pll.c ++++ b/drivers/clk/qcom/clk-alpha-pll.c +@@ -2444,6 +2444,8 @@ static int clk_alpha_pll_stromer_set_rat + rate = alpha_pll_round_rate(rate, prate, &l, &a, ALPHA_REG_BITWIDTH); + + regmap_write(pll->clkr.regmap, PLL_L_VAL(pll), l); ++ ++ a <<= ALPHA_REG_BITWIDTH - ALPHA_BITWIDTH; + regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), a); + regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL_U(pll), + a >> ALPHA_BITWIDTH); diff --git a/queue-6.6/crypto-ecdsa-fix-module-auto-load-on-add-key.patch b/queue-6.6/crypto-ecdsa-fix-module-auto-load-on-add-key.patch new file mode 100644 index 00000000000..557a7d797c5 --- /dev/null +++ b/queue-6.6/crypto-ecdsa-fix-module-auto-load-on-add-key.patch @@ -0,0 +1,56 @@ +From 48e4fd6d54f54d0ceab5a952d73e47a9454a6ccb Mon Sep 17 00:00:00 2001 +From: Stefan Berger +Date: Thu, 21 Mar 2024 10:44:33 -0400 +Subject: crypto: ecdsa - Fix module auto-load on add-key + +From: Stefan Berger + +commit 48e4fd6d54f54d0ceab5a952d73e47a9454a6ccb upstream. + +Add module alias with the algorithm cra_name similar to what we have for +RSA-related and other algorithms. + +The kernel attempts to modprobe asymmetric algorithms using the names +"crypto-$cra_name" and "crypto-$cra_name-all." However, since these +aliases are currently missing, the modules are not loaded. For instance, +when using the `add_key` function, the hash algorithm is typically +loaded automatically, but the asymmetric algorithm is not. + +Steps to test: + +1. Create certificate + + openssl req -x509 -sha256 -newkey ec \ + -pkeyopt "ec_paramgen_curve:secp384r1" -keyout key.pem -days 365 \ + -subj '/CN=test' -nodes -outform der -out nist-p384.der + +2. Optionally, trace module requests with: trace-cmd stream -e module & + +3. Trigger add_key call for the cert: + + # keyctl padd asymmetric "" @u < nist-p384.der + 641069229 + # lsmod | head -2 + Module Size Used by + ecdsa_generic 16384 0 + +Fixes: c12d448ba939 ("crypto: ecdsa - Register NIST P384 and extend test suite") +Cc: stable@vger.kernel.org +Signed-off-by: Stefan Berger +Reviewed-by: Vitaly Chikunov +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + crypto/ecdsa.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/crypto/ecdsa.c ++++ b/crypto/ecdsa.c +@@ -373,4 +373,7 @@ module_exit(ecdsa_exit); + MODULE_LICENSE("GPL"); + MODULE_AUTHOR("Stefan Berger "); + MODULE_DESCRIPTION("ECDSA generic algorithm"); ++MODULE_ALIAS_CRYPTO("ecdsa-nist-p192"); ++MODULE_ALIAS_CRYPTO("ecdsa-nist-p256"); ++MODULE_ALIAS_CRYPTO("ecdsa-nist-p384"); + MODULE_ALIAS_CRYPTO("ecdsa-generic"); diff --git a/queue-6.6/crypto-ecrdsa-fix-module-auto-load-on-add_key.patch b/queue-6.6/crypto-ecrdsa-fix-module-auto-load-on-add_key.patch new file mode 100644 index 00000000000..9a66d175088 --- /dev/null +++ b/queue-6.6/crypto-ecrdsa-fix-module-auto-load-on-add_key.patch @@ -0,0 +1,64 @@ +From eb5739a1efbc9ff216271aeea0ebe1c92e5383e5 Mon Sep 17 00:00:00 2001 +From: Vitaly Chikunov +Date: Mon, 18 Mar 2024 03:42:40 +0300 +Subject: crypto: ecrdsa - Fix module auto-load on add_key + +From: Vitaly Chikunov + +commit eb5739a1efbc9ff216271aeea0ebe1c92e5383e5 upstream. + +Add module alias with the algorithm cra_name similar to what we have for +RSA-related and other algorithms. + +The kernel attempts to modprobe asymmetric algorithms using the names +"crypto-$cra_name" and "crypto-$cra_name-all." However, since these +aliases are currently missing, the modules are not loaded. For instance, +when using the `add_key` function, the hash algorithm is typically +loaded automatically, but the asymmetric algorithm is not. + +Steps to test: + +1. Cert is generated usings ima-evm-utils test suite with + `gen-keys.sh`, example cert is provided below: + + $ base64 -d >test-gost2012_512-A.cer < +Cc: stable@vger.kernel.org +Signed-off-by: Vitaly Chikunov +Tested-by: Stefan Berger +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + crypto/ecrdsa.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/crypto/ecrdsa.c ++++ b/crypto/ecrdsa.c +@@ -294,4 +294,5 @@ module_exit(ecrdsa_mod_fini); + MODULE_LICENSE("GPL"); + MODULE_AUTHOR("Vitaly Chikunov "); + MODULE_DESCRIPTION("EC-RDSA generic algorithm"); ++MODULE_ALIAS_CRYPTO("ecrdsa"); + MODULE_ALIAS_CRYPTO("ecrdsa-generic"); diff --git a/queue-6.6/crypto-qat-fix-adf_dev_reset_sync-memory-leak.patch b/queue-6.6/crypto-qat-fix-adf_dev_reset_sync-memory-leak.patch new file mode 100644 index 00000000000..81b125bf575 --- /dev/null +++ b/queue-6.6/crypto-qat-fix-adf_dev_reset_sync-memory-leak.patch @@ -0,0 +1,71 @@ +From d3b17c6d9dddc2db3670bc9be628b122416a3d26 Mon Sep 17 00:00:00 2001 +From: Herbert Xu +Date: Wed, 8 May 2024 16:39:51 +0800 +Subject: crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak + +From: Herbert Xu + +commit d3b17c6d9dddc2db3670bc9be628b122416a3d26 upstream. + +Using completion_done to determine whether the caller has gone +away only works after a complete call. Furthermore it's still +possible that the caller has not yet called wait_for_completion, +resulting in another potential UAF. + +Fix this by making the caller use cancel_work_sync and then freeing +the memory safely. + +Fixes: 7d42e097607c ("crypto: qat - resolve race condition during AER recovery") +Cc: #6.8+ +Signed-off-by: Herbert Xu +Reviewed-by: Giovanni Cabiddu +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/crypto/intel/qat/qat_common/adf_aer.c | 19 +++++-------------- + 1 file changed, 5 insertions(+), 14 deletions(-) + +--- a/drivers/crypto/intel/qat/qat_common/adf_aer.c ++++ b/drivers/crypto/intel/qat/qat_common/adf_aer.c +@@ -92,8 +92,7 @@ static void adf_device_reset_worker(stru + if (adf_dev_restart(accel_dev)) { + /* The device hanged and we can't restart it so stop here */ + dev_err(&GET_DEV(accel_dev), "Restart device failed\n"); +- if (reset_data->mode == ADF_DEV_RESET_ASYNC || +- completion_done(&reset_data->compl)) ++ if (reset_data->mode == ADF_DEV_RESET_ASYNC) + kfree(reset_data); + WARN(1, "QAT: device restart failed. Device is unusable\n"); + return; +@@ -101,16 +100,8 @@ static void adf_device_reset_worker(stru + adf_dev_restarted_notify(accel_dev); + clear_bit(ADF_STATUS_RESTARTING, &accel_dev->status); + +- /* +- * The dev is back alive. Notify the caller if in sync mode +- * +- * If device restart will take a more time than expected, +- * the schedule_reset() function can timeout and exit. This can be +- * detected by calling the completion_done() function. In this case +- * the reset_data structure needs to be freed here. +- */ +- if (reset_data->mode == ADF_DEV_RESET_ASYNC || +- completion_done(&reset_data->compl)) ++ /* The dev is back alive. Notify the caller if in sync mode */ ++ if (reset_data->mode == ADF_DEV_RESET_ASYNC) + kfree(reset_data); + else + complete(&reset_data->compl); +@@ -145,10 +136,10 @@ static int adf_dev_aer_schedule_reset(st + if (!timeout) { + dev_err(&GET_DEV(accel_dev), + "Reset device timeout expired\n"); ++ cancel_work_sync(&reset_data->reset_work); + ret = -EFAULT; +- } else { +- kfree(reset_data); + } ++ kfree(reset_data); + return ret; + } + return 0; diff --git a/queue-6.6/drm-amd-fix-shutdown-again-on-some-smu-v13.0.4-11-platforms.patch b/queue-6.6/drm-amd-fix-shutdown-again-on-some-smu-v13.0.4-11-platforms.patch new file mode 100644 index 00000000000..a0465a5af6f --- /dev/null +++ b/queue-6.6/drm-amd-fix-shutdown-again-on-some-smu-v13.0.4-11-platforms.patch @@ -0,0 +1,61 @@ +From 267cace556e8a53d703119f7435ab556209e5b6a Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Sun, 26 May 2024 07:59:08 -0500 +Subject: drm/amd: Fix shutdown (again) on some SMU v13.0.4/11 platforms + +From: Mario Limonciello + +commit 267cace556e8a53d703119f7435ab556209e5b6a upstream. + +commit cd94d1b182d2 ("dm/amd/pm: Fix problems with reboot/shutdown for +some SMU 13.0.4/13.0.11 users") attempted to fix shutdown issues +that were reported since commit 31729e8c21ec ("drm/amd/pm: fixes a +random hang in S4 for SMU v13.0.4/11") but caused issues for some +people. + +Adjust the workaround flow to properly only apply in the S4 case: +-> For shutdown go through SMU_MSG_PrepareMp1ForUnload +-> For S4 go through SMU_MSG_GfxDeviceDriverReset and + SMU_MSG_PrepareMp1ForUnload + +Reported-and-tested-by: lectrode +Closes: https://github.com/void-linux/void-packages/issues/50417 +Cc: stable@vger.kernel.org +Fixes: cd94d1b182d2 ("dm/amd/pm: Fix problems with reboot/shutdown for some SMU 13.0.4/13.0.11 users") +Reviewed-by: Tim Huang +Signed-off-by: Mario Limonciello +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 20 ++++++++++--------- + 1 file changed, 11 insertions(+), 9 deletions(-) + +--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c ++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c +@@ -226,15 +226,17 @@ static int smu_v13_0_4_system_features_c + struct amdgpu_device *adev = smu->adev; + int ret = 0; + +- if (!en && adev->in_s4) { +- /* Adds a GFX reset as workaround just before sending the +- * MP1_UNLOAD message to prevent GC/RLC/PMFW from entering +- * an invalid state. +- */ +- ret = smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_GfxDeviceDriverReset, +- SMU_RESET_MODE_2, NULL); +- if (ret) +- return ret; ++ if (!en && !adev->in_s0ix) { ++ if (adev->in_s4) { ++ /* Adds a GFX reset as workaround just before sending the ++ * MP1_UNLOAD message to prevent GC/RLC/PMFW from entering ++ * an invalid state. ++ */ ++ ret = smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_GfxDeviceDriverReset, ++ SMU_RESET_MODE_2, NULL); ++ if (ret) ++ return ret; ++ } + + ret = smu_cmn_send_smc_msg(smu, SMU_MSG_PrepareMp1ForUnload, NULL); + } diff --git a/queue-6.6/kbuild-remove-support-for-clang-s-thinlto-caching.patch b/queue-6.6/kbuild-remove-support-for-clang-s-thinlto-caching.patch new file mode 100644 index 00000000000..b47ede6d627 --- /dev/null +++ b/queue-6.6/kbuild-remove-support-for-clang-s-thinlto-caching.patch @@ -0,0 +1,134 @@ +From aba091547ef6159d52471f42a3ef531b7b660ed8 Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Wed, 1 May 2024 15:55:25 -0700 +Subject: kbuild: Remove support for Clang's ThinLTO caching +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Nathan Chancellor + +commit aba091547ef6159d52471f42a3ef531b7b660ed8 upstream. + +There is an issue in clang's ThinLTO caching (enabled for the kernel via +'--thinlto-cache-dir') with .incbin, which the kernel occasionally uses +to include data within the kernel, such as the .config file for +/proc/config.gz. For example, when changing the .config and rebuilding +vmlinux, the copy of .config in vmlinux does not match the copy of +.config in the build folder: + + $ echo 'CONFIG_LTO_NONE=n + CONFIG_LTO_CLANG_THIN=y + CONFIG_IKCONFIG=y + CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config + + $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux + ... + + $ grep CONFIG_HEADERS_INSTALL .config + CONFIG_HEADERS_INSTALL=y + + $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL + CONFIG_HEADERS_INSTALL=y + + $ scripts/config -d HEADERS_INSTALL + + $ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux + ... + UPD kernel/config_data + GZIP kernel/config_data.gz + CC kernel/configs.o + ... + LD vmlinux + ... + + $ grep CONFIG_HEADERS_INSTALL .config + # CONFIG_HEADERS_INSTALL is not set + + $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL + CONFIG_HEADERS_INSTALL=y + +Without '--thinlto-cache-dir' or when using full LTO, this issue does +not occur. + +Benchmarking incremental builds on a few different machines with and +without the cache shows a 20% increase in incremental build time without +the cache when measured by touching init/main.c and running 'make all'. + +ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host: + + Benchmark 1: With ThinLTO cache + Time (mean ± σ): 56.347 s ± 0.163 s [User: 83.768 s, System: 24.661 s] + Range (min … max): 56.109 s … 56.594 s 10 runs + + Benchmark 2: Without ThinLTO cache + Time (mean ± σ): 67.740 s ± 0.479 s [User: 718.458 s, System: 31.797 s] + Range (min … max): 67.059 s … 68.556 s 10 runs + + Summary + With ThinLTO cache ran + 1.20 ± 0.01 times faster than Without ThinLTO cache + +ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host: + + Benchmark 1: With ThinLTO cache + Time (mean ± σ): 85.772 s ± 0.252 s [User: 91.505 s, System: 8.408 s] + Range (min … max): 85.447 s … 86.244 s 10 runs + + Benchmark 2: Without ThinLTO cache + Time (mean ± σ): 103.833 s ± 0.288 s [User: 232.058 s, System: 8.569 s] + Range (min … max): 103.286 s … 104.124 s 10 runs + + Summary + With ThinLTO cache ran + 1.21 ± 0.00 times faster than Without ThinLTO cache + +While it is unfortunate to take this performance improvement off the +table, correctness is more important. If/when this is fixed in LLVM, it +can potentially be brought back in a conditional manner. Alternatively, +a developer can just disable LTO if doing incremental compiles quickly +is important, as a full compile cycle can still take over a minute even +with the cache and it is unlikely that LTO will result in functional +differences for a kernel change. + +Cc: stable@vger.kernel.org +Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO") +Reported-by: Yifan Hong +Closes: https://github.com/ClangBuiltLinux/linux/issues/2021 +Reported-by: Masami Hiramatsu +Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.org/ +Signed-off-by: Nathan Chancellor +Signed-off-by: Masahiro Yamada +Signed-off-by: Greg Kroah-Hartman +--- + Makefile | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/Makefile ++++ b/Makefile +@@ -951,7 +951,6 @@ endif + ifdef CONFIG_LTO_CLANG + ifdef CONFIG_LTO_CLANG_THIN + CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit +-KBUILD_LDFLAGS += --thinlto-cache-dir=$(extmod_prefix).thinlto-cache + else + CC_FLAGS_LTO := -flto + endif +@@ -1482,7 +1481,7 @@ endif # CONFIG_MODULES + # Directories & files removed with 'make clean' + CLEAN_FILES += vmlinux.symvers modules-only.symvers \ + modules.builtin modules.builtin.modinfo modules.nsdeps \ +- compile_commands.json .thinlto-cache rust/test \ ++ compile_commands.json rust/test \ + rust-project.json .vmlinux.objs .vmlinux.export.c + + # Directories & files removed with 'make mrproper' +@@ -1786,7 +1785,7 @@ PHONY += compile_commands.json + + clean-dirs := $(KBUILD_EXTMOD) + clean: rm-files := $(KBUILD_EXTMOD)/Module.symvers $(KBUILD_EXTMOD)/modules.nsdeps \ +- $(KBUILD_EXTMOD)/compile_commands.json $(KBUILD_EXTMOD)/.thinlto-cache ++ $(KBUILD_EXTMOD)/compile_commands.json + + PHONY += prepare + # now expand this into a simple variable to reduce the cost of shell evaluations diff --git a/queue-6.6/kvm-arm64-aarch32-fix-spurious-trapping-of-conditional-instructions.patch b/queue-6.6/kvm-arm64-aarch32-fix-spurious-trapping-of-conditional-instructions.patch new file mode 100644 index 00000000000..3f56f3862d1 --- /dev/null +++ b/queue-6.6/kvm-arm64-aarch32-fix-spurious-trapping-of-conditional-instructions.patch @@ -0,0 +1,65 @@ +From c92e8b9eacebb4060634ebd9395bba1b29aadc68 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Fri, 24 May 2024 15:19:56 +0100 +Subject: KVM: arm64: AArch32: Fix spurious trapping of conditional instructions + +From: Marc Zyngier + +commit c92e8b9eacebb4060634ebd9395bba1b29aadc68 upstream. + +We recently upgraded the view of ESR_EL2 to 64bit, in keeping with +the requirements of the architecture. + +However, the AArch32 emulation code was left unaudited, and the +(already dodgy) code that triages whether a trap is spurious or not +(because the condition code failed) broke in a subtle way: + +If ESR_EL2.ISS2 is ever non-zero (unlikely, but hey, this is the ARM +architecture we're talking about), the hack that tests the top bits +of ESR_EL2.EC will break in an interesting way. + +Instead, use kvm_vcpu_trap_get_class() to obtain the EC, and list +all the possible ECs that can fail a condition code check. + +While we're at it, add SMC32 to the list, as it is explicitly listed +as being allowed to trap despite failing a condition code check (as +described in the HCR_EL2.TSC documentation). + +Fixes: 0b12620fddb8 ("KVM: arm64: Treat ESR_EL2 as a 64-bit register") +Cc: stable@vger.kernel.org +Acked-by: Oliver Upton +Link: https://lore.kernel.org/r/20240524141956.1450304-4-maz@kernel.org +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kvm/hyp/aarch32.c | 18 ++++++++++++++++-- + 1 file changed, 16 insertions(+), 2 deletions(-) + +--- a/arch/arm64/kvm/hyp/aarch32.c ++++ b/arch/arm64/kvm/hyp/aarch32.c +@@ -50,9 +50,23 @@ bool kvm_condition_valid32(const struct + u32 cpsr_cond; + int cond; + +- /* Top two bits non-zero? Unconditional. */ +- if (kvm_vcpu_get_esr(vcpu) >> 30) ++ /* ++ * These are the exception classes that could fire with a ++ * conditional instruction. ++ */ ++ switch (kvm_vcpu_trap_get_class(vcpu)) { ++ case ESR_ELx_EC_CP15_32: ++ case ESR_ELx_EC_CP15_64: ++ case ESR_ELx_EC_CP14_MR: ++ case ESR_ELx_EC_CP14_LS: ++ case ESR_ELx_EC_FP_ASIMD: ++ case ESR_ELx_EC_CP10_ID: ++ case ESR_ELx_EC_CP14_64: ++ case ESR_ELx_EC_SVC32: ++ break; ++ default: + return true; ++ } + + /* Is condition field valid? */ + cond = kvm_vcpu_get_condition(vcpu); diff --git a/queue-6.6/kvm-arm64-allow-aarch32-pstate.m-to-be-restored-as-system-mode.patch b/queue-6.6/kvm-arm64-allow-aarch32-pstate.m-to-be-restored-as-system-mode.patch new file mode 100644 index 00000000000..ec4d73e639b --- /dev/null +++ b/queue-6.6/kvm-arm64-allow-aarch32-pstate.m-to-be-restored-as-system-mode.patch @@ -0,0 +1,34 @@ +From dfe6d190f38fc5df5ff2614b463a5195a399c885 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Fri, 24 May 2024 15:19:55 +0100 +Subject: KVM: arm64: Allow AArch32 PSTATE.M to be restored as System mode + +From: Marc Zyngier + +commit dfe6d190f38fc5df5ff2614b463a5195a399c885 upstream. + +It appears that we don't allow a vcpu to be restored in AArch32 +System mode, as we *never* included it in the list of valid modes. + +Just add it to the list of allowed modes. + +Fixes: 0d854a60b1d7 ("arm64: KVM: enable initialization of a 32bit vcpu") +Cc: stable@vger.kernel.org +Acked-by: Oliver Upton +Link: https://lore.kernel.org/r/20240524141956.1450304-3-maz@kernel.org +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kvm/guest.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/arm64/kvm/guest.c ++++ b/arch/arm64/kvm/guest.c +@@ -251,6 +251,7 @@ static int set_core_reg(struct kvm_vcpu + case PSR_AA32_MODE_SVC: + case PSR_AA32_MODE_ABT: + case PSR_AA32_MODE_UND: ++ case PSR_AA32_MODE_SYS: + if (!vcpu_el1_is_32bit(vcpu)) + return -EINVAL; + break; diff --git a/queue-6.6/kvm-arm64-fix-aarch32-register-narrowing-on-userspace-write.patch b/queue-6.6/kvm-arm64-fix-aarch32-register-narrowing-on-userspace-write.patch new file mode 100644 index 00000000000..e54bd8702a9 --- /dev/null +++ b/queue-6.6/kvm-arm64-fix-aarch32-register-narrowing-on-userspace-write.patch @@ -0,0 +1,49 @@ +From 947051e361d551e0590777080ffc4926190f62f2 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Fri, 24 May 2024 15:19:54 +0100 +Subject: KVM: arm64: Fix AArch32 register narrowing on userspace write + +From: Marc Zyngier + +commit 947051e361d551e0590777080ffc4926190f62f2 upstream. + +When userspace writes to one of the core registers, we make +sure to narrow the corresponding GPRs if PSTATE indicates +an AArch32 context. + +The code tries to check whether the context is EL0 or EL1 so +that it narrows the correct registers. But it does so by checking +the full PSTATE instead of PSTATE.M. + +As a consequence, and if we are restoring an AArch32 EL0 context +in a 64bit guest, and that PSTATE has *any* bit set outside of +PSTATE.M, we narrow *all* registers instead of only the first 15, +destroying the 64bit state. + +Obviously, this is not something the guest is likely to enjoy. + +Correctly masking PSTATE to only evaluate PSTATE.M fixes it. + +Fixes: 90c1f934ed71 ("KVM: arm64: Get rid of the AArch32 register mapping code") +Reported-by: Nina Schoetterl-Glausch +Cc: stable@vger.kernel.org +Reviewed-by: Nina Schoetterl-Glausch +Acked-by: Oliver Upton +Link: https://lore.kernel.org/r/20240524141956.1450304-2-maz@kernel.org +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kvm/guest.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm64/kvm/guest.c ++++ b/arch/arm64/kvm/guest.c +@@ -276,7 +276,7 @@ static int set_core_reg(struct kvm_vcpu + if (*vcpu_cpsr(vcpu) & PSR_MODE32_BIT) { + int i, nr_reg; + +- switch (*vcpu_cpsr(vcpu)) { ++ switch (*vcpu_cpsr(vcpu) & PSR_AA32_MODE_MASK) { + /* + * Either we are dealing with user mode, and only the + * first 15 registers (+ PC) must be narrowed to 32bit. diff --git a/queue-6.6/kvm-svm-warn-on-vnmi-nmi-window-iff-nmis-are-outright-masked.patch b/queue-6.6/kvm-svm-warn-on-vnmi-nmi-window-iff-nmis-are-outright-masked.patch new file mode 100644 index 00000000000..c35fd8d503c --- /dev/null +++ b/queue-6.6/kvm-svm-warn-on-vnmi-nmi-window-iff-nmis-are-outright-masked.patch @@ -0,0 +1,86 @@ +From b4bd556467477420ee3a91fbcba73c579669edc6 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 21 May 2024 19:14:35 -0700 +Subject: KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked + +From: Sean Christopherson + +commit b4bd556467477420ee3a91fbcba73c579669edc6 upstream. + +When requesting an NMI window, WARN on vNMI support being enabled if and +only if NMIs are actually masked, i.e. if the vCPU is already handling an +NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of +view) is to inject one NMI and pend the other. When using vNMI, KVM pends +the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the +rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). + +However, if KVM can't immediately inject an NMI, e.g. because the vCPU is +in an STI shadow or is running with GIF=0, then KVM will request an NMI +window and trigger the WARN (but still function correctly). + +Whether or not the GIF=0 case makes sense is debatable, as the intent of +KVM's behavior is to provide functionality that is as close to real +hardware as possible. E.g. if two NMIs are sent in quick succession, the +probability of both NMIs arriving in an STI shadow is infinitesimally low +on real hardware, but significantly larger in a virtual environment, e.g. +if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't +as clear cut, because the window where two NMIs can collide is much larger +in bare metal (though still small). + +That said, KVM should not have divergent behavior for the GIF=0 case based +on whether or not vNMI support is enabled. And KVM has allowed +simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 +("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be +modified without a *really* good reason to do so, and if KVM's behavior +were to be modified, it should be done irrespective of vNMI support. + +Fixes: fa4c027a7956 ("KVM: x86: Add support for SVM's Virtual NMI") +Cc: stable@vger.kernel.org +Cc: Santosh Shukla +Cc: Maxim Levitsky +Signed-off-by: Sean Christopherson +Message-ID: <20240522021435.1684366-1-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 27 +++++++++++++++++++-------- + 1 file changed, 19 insertions(+), 8 deletions(-) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -3856,16 +3856,27 @@ static void svm_enable_nmi_window(struct + struct vcpu_svm *svm = to_svm(vcpu); + + /* +- * KVM should never request an NMI window when vNMI is enabled, as KVM +- * allows at most one to-be-injected NMI and one pending NMI, i.e. if +- * two NMIs arrive simultaneously, KVM will inject one and set +- * V_NMI_PENDING for the other. WARN, but continue with the standard +- * single-step approach to try and salvage the pending NMI. ++ * If NMIs are outright masked, i.e. the vCPU is already handling an ++ * NMI, and KVM has not yet intercepted an IRET, then there is nothing ++ * more to do at this time as KVM has already enabled IRET intercepts. ++ * If KVM has already intercepted IRET, then single-step over the IRET, ++ * as NMIs aren't architecturally unmasked until the IRET completes. ++ * ++ * If vNMI is enabled, KVM should never request an NMI window if NMIs ++ * are masked, as KVM allows at most one to-be-injected NMI and one ++ * pending NMI. If two NMIs arrive simultaneously, KVM will inject one ++ * NMI and set V_NMI_PENDING for the other, but if and only if NMIs are ++ * unmasked. KVM _will_ request an NMI window in some situations, e.g. ++ * if the vCPU is in an STI shadow or if GIF=0, KVM can't immediately ++ * inject the NMI. In those situations, KVM needs to single-step over ++ * the STI shadow or intercept STGI. + */ +- WARN_ON_ONCE(is_vnmi_enabled(svm)); ++ if (svm_get_nmi_mask(vcpu)) { ++ WARN_ON_ONCE(is_vnmi_enabled(svm)); + +- if (svm_get_nmi_mask(vcpu) && !svm->awaiting_iret_completion) +- return; /* IRET will cause a vm exit */ ++ if (!svm->awaiting_iret_completion) ++ return; /* IRET will cause a vm exit */ ++ } + + /* + * SEV-ES guests are responsible for signaling when a vCPU is ready to diff --git a/queue-6.6/loongarch-add-all-cpus-enabled-by-fdt-to-numa-node-0.patch b/queue-6.6/loongarch-add-all-cpus-enabled-by-fdt-to-numa-node-0.patch new file mode 100644 index 00000000000..a598738a431 --- /dev/null +++ b/queue-6.6/loongarch-add-all-cpus-enabled-by-fdt-to-numa-node-0.patch @@ -0,0 +1,63 @@ +From 3de9c42d02a79a5e09bbee7a4421ddc00cfd5c6d Mon Sep 17 00:00:00 2001 +From: Jiaxun Yang +Date: Mon, 3 Jun 2024 15:45:53 +0800 +Subject: LoongArch: Add all CPUs enabled by fdt to NUMA node 0 + +From: Jiaxun Yang + +commit 3de9c42d02a79a5e09bbee7a4421ddc00cfd5c6d upstream. + +NUMA enabled kernel on FDT based machine fails to boot because CPUs +are all in NUMA_NO_NODE and mm subsystem won't accept that. + +Fix by adding them to default NUMA node at FDT parsing phase and move +numa_add_cpu(0) to a later point. + +Cc: stable@vger.kernel.org +Fixes: 88d4d957edc7 ("LoongArch: Add FDT booting support from efi system table") +Signed-off-by: Jiaxun Yang +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/include/asm/numa.h | 1 + + arch/loongarch/kernel/smp.c | 5 ++++- + 2 files changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/loongarch/include/asm/numa.h ++++ b/arch/loongarch/include/asm/numa.h +@@ -56,6 +56,7 @@ extern int early_cpu_to_node(int cpu); + static inline void early_numa_add_cpu(int cpuid, s16 node) { } + static inline void numa_add_cpu(unsigned int cpu) { } + static inline void numa_remove_cpu(unsigned int cpu) { } ++static inline void set_cpuid_to_node(int cpuid, s16 node) { } + + static inline int early_cpu_to_node(int cpu) + { +--- a/arch/loongarch/kernel/smp.c ++++ b/arch/loongarch/kernel/smp.c +@@ -262,7 +262,6 @@ static void __init fdt_smp_setup(void) + + if (cpuid == loongson_sysconf.boot_cpu_id) { + cpu = 0; +- numa_add_cpu(cpu); + } else { + cpu = cpumask_next_zero(-1, cpu_present_mask); + } +@@ -272,6 +271,9 @@ static void __init fdt_smp_setup(void) + set_cpu_present(cpu, true); + __cpu_number_map[cpuid] = cpu; + __cpu_logical_map[cpu] = cpuid; ++ ++ early_numa_add_cpu(cpu, 0); ++ set_cpuid_to_node(cpuid, 0); + } + + loongson_sysconf.nr_cpus = num_processors; +@@ -453,6 +455,7 @@ void smp_prepare_boot_cpu(void) + set_cpu_possible(0, true); + set_cpu_online(0, true); + set_my_cpu_offset(per_cpu_offset(0)); ++ numa_add_cpu(0); + + rr_node = first_node(node_online_map); + for_each_possible_cpu(cpu) { diff --git a/queue-6.6/loongarch-override-higher-address-bits-in-jump_virt_addr.patch b/queue-6.6/loongarch-override-higher-address-bits-in-jump_virt_addr.patch new file mode 100644 index 00000000000..12f891e0b7b --- /dev/null +++ b/queue-6.6/loongarch-override-higher-address-bits-in-jump_virt_addr.patch @@ -0,0 +1,38 @@ +From 1098efd299ffe9c8af818425338c7f6c4f930a98 Mon Sep 17 00:00:00 2001 +From: Jiaxun Yang +Date: Mon, 3 Jun 2024 15:45:53 +0800 +Subject: LoongArch: Override higher address bits in JUMP_VIRT_ADDR + +From: Jiaxun Yang + +commit 1098efd299ffe9c8af818425338c7f6c4f930a98 upstream. + +In JUMP_VIRT_ADDR we are performing an or calculation on address value +directly from pcaddi. + +This will only work if we are currently running from direct 1:1 mapping +addresses or firmware's DMW is configured exactly same as kernel. Still, +we should not rely on such assumption. + +Fix by overriding higher bits in address comes from pcaddi, so we can +get rid of or operator. + +Cc: stable@vger.kernel.org +Signed-off-by: Jiaxun Yang +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/include/asm/stackframe.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/loongarch/include/asm/stackframe.h ++++ b/arch/loongarch/include/asm/stackframe.h +@@ -41,7 +41,7 @@ + .macro JUMP_VIRT_ADDR temp1 temp2 + li.d \temp1, CACHE_BASE + pcaddi \temp2, 0 +- or \temp1, \temp1, \temp2 ++ bstrins.d \temp1, \temp2, (DMW_PABITS - 1), 0 + jirl zero, \temp1, 0xc + .endm + diff --git a/queue-6.6/mm-fix-race-between-__split_huge_pmd_locked-and-gup-fast.patch b/queue-6.6/mm-fix-race-between-__split_huge_pmd_locked-and-gup-fast.patch new file mode 100644 index 00000000000..43009380b93 --- /dev/null +++ b/queue-6.6/mm-fix-race-between-__split_huge_pmd_locked-and-gup-fast.patch @@ -0,0 +1,225 @@ +From 3a5a8d343e1cf96eb9971b17cbd4b832ab19b8e7 Mon Sep 17 00:00:00 2001 +From: Ryan Roberts +Date: Wed, 1 May 2024 15:33:10 +0100 +Subject: mm: fix race between __split_huge_pmd_locked() and GUP-fast + +From: Ryan Roberts + +commit 3a5a8d343e1cf96eb9971b17cbd4b832ab19b8e7 upstream. + +__split_huge_pmd_locked() can be called for a present THP, devmap or +(non-present) migration entry. It calls pmdp_invalidate() unconditionally +on the pmdp and only determines if it is present or not based on the +returned old pmd. This is a problem for the migration entry case because +pmd_mkinvalid(), called by pmdp_invalidate() must only be called for a +present pmd. + +On arm64 at least, pmd_mkinvalid() will mark the pmd such that any future +call to pmd_present() will return true. And therefore any lockless +pgtable walker could see the migration entry pmd in this state and start +interpretting the fields as if it were present, leading to BadThings (TM). +GUP-fast appears to be one such lockless pgtable walker. + +x86 does not suffer the above problem, but instead pmd_mkinvalid() will +corrupt the offset field of the swap entry within the swap pte. See link +below for discussion of that problem. + +Fix all of this by only calling pmdp_invalidate() for a present pmd. And +for good measure let's add a warning to all implementations of +pmdp_invalidate[_ad](). I've manually reviewed all other +pmdp_invalidate[_ad]() call sites and believe all others to be conformant. + +This is a theoretical bug found during code review. I don't have any test +case to trigger it in practice. + +Link: https://lkml.kernel.org/r/20240501143310.1381675-1-ryan.roberts@arm.com +Link: https://lore.kernel.org/all/0dd7827a-6334-439a-8fd0-43c98e6af22b@arm.com/ +Fixes: 84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path") +Signed-off-by: Ryan Roberts +Reviewed-by: Zi Yan +Reviewed-by: Anshuman Khandual +Acked-by: David Hildenbrand +Cc: Andreas Larsson +Cc: Andy Lutomirski +Cc: Aneesh Kumar K.V +Cc: Borislav Petkov (AMD) +Cc: Catalin Marinas +Cc: Christian Borntraeger +Cc: Christophe Leroy +Cc: Dave Hansen +Cc: "David S. Miller" +Cc: Ingo Molnar +Cc: Jonathan Corbet +Cc: Mark Rutland +Cc: Naveen N. Rao +Cc: Nicholas Piggin +Cc: Peter Zijlstra +Cc: Sven Schnelle +Cc: Thomas Gleixner +Cc: Will Deacon +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/mm/arch_pgtable_helpers.rst | 6 ++- + arch/powerpc/mm/book3s64/pgtable.c | 1 + arch/s390/include/asm/pgtable.h | 4 +- + arch/sparc/mm/tlb.c | 1 + arch/x86/mm/pgtable.c | 2 + + mm/huge_memory.c | 49 +++++++++++++++--------------- + mm/pgtable-generic.c | 2 + + 7 files changed, 39 insertions(+), 26 deletions(-) + +--- a/Documentation/mm/arch_pgtable_helpers.rst ++++ b/Documentation/mm/arch_pgtable_helpers.rst +@@ -142,7 +142,8 @@ PMD Page Table Helpers + +---------------------------+--------------------------------------------------+ + | pmd_swp_clear_soft_dirty | Clears a soft dirty swapped PMD | + +---------------------------+--------------------------------------------------+ +-| pmd_mkinvalid | Invalidates a mapped PMD [1] | ++| pmd_mkinvalid | Invalidates a present PMD; do not call for | ++| | non-present PMD [1] | + +---------------------------+--------------------------------------------------+ + | pmd_set_huge | Creates a PMD huge mapping | + +---------------------------+--------------------------------------------------+ +@@ -198,7 +199,8 @@ PUD Page Table Helpers + +---------------------------+--------------------------------------------------+ + | pud_mkdevmap | Creates a ZONE_DEVICE mapped PUD | + +---------------------------+--------------------------------------------------+ +-| pud_mkinvalid | Invalidates a mapped PUD [1] | ++| pud_mkinvalid | Invalidates a present PUD; do not call for | ++| | non-present PUD [1] | + +---------------------------+--------------------------------------------------+ + | pud_set_huge | Creates a PUD huge mapping | + +---------------------------+--------------------------------------------------+ +--- a/arch/powerpc/mm/book3s64/pgtable.c ++++ b/arch/powerpc/mm/book3s64/pgtable.c +@@ -170,6 +170,7 @@ pmd_t pmdp_invalidate(struct vm_area_str + { + unsigned long old_pmd; + ++ VM_WARN_ON_ONCE(!pmd_present(*pmdp)); + old_pmd = pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_PRESENT, _PAGE_INVALID); + flush_pmd_tlb_range(vma, address, address + HPAGE_PMD_SIZE); + return __pmd(old_pmd); +--- a/arch/s390/include/asm/pgtable.h ++++ b/arch/s390/include/asm/pgtable.h +@@ -1774,8 +1774,10 @@ static inline pmd_t pmdp_huge_clear_flus + static inline pmd_t pmdp_invalidate(struct vm_area_struct *vma, + unsigned long addr, pmd_t *pmdp) + { +- pmd_t pmd = __pmd(pmd_val(*pmdp) | _SEGMENT_ENTRY_INVALID); ++ pmd_t pmd; + ++ VM_WARN_ON_ONCE(!pmd_present(*pmdp)); ++ pmd = __pmd(pmd_val(*pmdp) | _SEGMENT_ENTRY_INVALID); + return pmdp_xchg_direct(vma->vm_mm, addr, pmdp, pmd); + } + +--- a/arch/sparc/mm/tlb.c ++++ b/arch/sparc/mm/tlb.c +@@ -249,6 +249,7 @@ pmd_t pmdp_invalidate(struct vm_area_str + { + pmd_t old, entry; + ++ VM_WARN_ON_ONCE(!pmd_present(*pmdp)); + entry = __pmd(pmd_val(*pmdp) & ~_PAGE_VALID); + old = pmdp_establish(vma, address, pmdp, entry); + flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE); +--- a/arch/x86/mm/pgtable.c ++++ b/arch/x86/mm/pgtable.c +@@ -628,6 +628,8 @@ int pmdp_clear_flush_young(struct vm_are + pmd_t pmdp_invalidate_ad(struct vm_area_struct *vma, unsigned long address, + pmd_t *pmdp) + { ++ VM_WARN_ON_ONCE(!pmd_present(*pmdp)); ++ + /* + * No flush is necessary. Once an invalid PTE is established, the PTE's + * access and dirty bits cannot be updated. +--- a/mm/huge_memory.c ++++ b/mm/huge_memory.c +@@ -2125,32 +2125,11 @@ static void __split_huge_pmd_locked(stru + return __split_huge_zero_page_pmd(vma, haddr, pmd); + } + +- /* +- * Up to this point the pmd is present and huge and userland has the +- * whole access to the hugepage during the split (which happens in +- * place). If we overwrite the pmd with the not-huge version pointing +- * to the pte here (which of course we could if all CPUs were bug +- * free), userland could trigger a small page size TLB miss on the +- * small sized TLB while the hugepage TLB entry is still established in +- * the huge TLB. Some CPU doesn't like that. +- * See http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf, Erratum +- * 383 on page 105. Intel should be safe but is also warns that it's +- * only safe if the permission and cache attributes of the two entries +- * loaded in the two TLB is identical (which should be the case here). +- * But it is generally safer to never allow small and huge TLB entries +- * for the same virtual address to be loaded simultaneously. So instead +- * of doing "pmd_populate(); flush_pmd_tlb_range();" we first mark the +- * current pmd notpresent (atomically because here the pmd_trans_huge +- * must remain set at all times on the pmd until the split is complete +- * for this pmd), then we flush the SMP TLB and finally we write the +- * non-huge version of the pmd entry with pmd_populate. +- */ +- old_pmd = pmdp_invalidate(vma, haddr, pmd); +- +- pmd_migration = is_pmd_migration_entry(old_pmd); ++ pmd_migration = is_pmd_migration_entry(*pmd); + if (unlikely(pmd_migration)) { + swp_entry_t entry; + ++ old_pmd = *pmd; + entry = pmd_to_swp_entry(old_pmd); + page = pfn_swap_entry_to_page(entry); + write = is_writable_migration_entry(entry); +@@ -2161,6 +2140,30 @@ static void __split_huge_pmd_locked(stru + soft_dirty = pmd_swp_soft_dirty(old_pmd); + uffd_wp = pmd_swp_uffd_wp(old_pmd); + } else { ++ /* ++ * Up to this point the pmd is present and huge and userland has ++ * the whole access to the hugepage during the split (which ++ * happens in place). If we overwrite the pmd with the not-huge ++ * version pointing to the pte here (which of course we could if ++ * all CPUs were bug free), userland could trigger a small page ++ * size TLB miss on the small sized TLB while the hugepage TLB ++ * entry is still established in the huge TLB. Some CPU doesn't ++ * like that. See ++ * http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf, Erratum ++ * 383 on page 105. Intel should be safe but is also warns that ++ * it's only safe if the permission and cache attributes of the ++ * two entries loaded in the two TLB is identical (which should ++ * be the case here). But it is generally safer to never allow ++ * small and huge TLB entries for the same virtual address to be ++ * loaded simultaneously. So instead of doing "pmd_populate(); ++ * flush_pmd_tlb_range();" we first mark the current pmd ++ * notpresent (atomically because here the pmd_trans_huge must ++ * remain set at all times on the pmd until the split is ++ * complete for this pmd), then we flush the SMP TLB and finally ++ * we write the non-huge version of the pmd entry with ++ * pmd_populate. ++ */ ++ old_pmd = pmdp_invalidate(vma, haddr, pmd); + page = pmd_page(old_pmd); + if (pmd_dirty(old_pmd)) { + dirty = true; +--- a/mm/pgtable-generic.c ++++ b/mm/pgtable-generic.c +@@ -198,6 +198,7 @@ pgtable_t pgtable_trans_huge_withdraw(st + pmd_t pmdp_invalidate(struct vm_area_struct *vma, unsigned long address, + pmd_t *pmdp) + { ++ VM_WARN_ON_ONCE(!pmd_present(*pmdp)); + pmd_t old = pmdp_establish(vma, address, pmdp, pmd_mkinvalid(*pmdp)); + flush_pmd_tlb_range(vma, address, address + HPAGE_PMD_SIZE); + return old; +@@ -208,6 +209,7 @@ pmd_t pmdp_invalidate(struct vm_area_str + pmd_t pmdp_invalidate_ad(struct vm_area_struct *vma, unsigned long address, + pmd_t *pmdp) + { ++ VM_WARN_ON_ONCE(!pmd_present(*pmdp)); + return pmdp_invalidate(vma, address, pmdp); + } + #endif diff --git a/queue-6.6/revert-drm-amdkfd-fix-gfx_target_version-for-certain-11.0.3-devices.patch b/queue-6.6/revert-drm-amdkfd-fix-gfx_target_version-for-certain-11.0.3-devices.patch new file mode 100644 index 00000000000..7d6d382cdb7 --- /dev/null +++ b/queue-6.6/revert-drm-amdkfd-fix-gfx_target_version-for-certain-11.0.3-devices.patch @@ -0,0 +1,42 @@ +From dd2b75fd9a79bf418e088656822af06fc253dbe3 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 20 May 2024 14:41:31 -0400 +Subject: Revert "drm/amdkfd: fix gfx_target_version for certain 11.0.3 devices" + +From: Alex Deucher + +commit dd2b75fd9a79bf418e088656822af06fc253dbe3 upstream. + +This reverts commit 28ebbb4981cb1fad12e0b1227dbecc88810b1ee8. + +Revert this commit as apparently the LLVM code to take advantage of +this never landed. + +Reviewed-by: Feifei Xu +Signed-off-by: Alex Deucher +Cc: Feifei Xu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdkfd/kfd_device.c | 11 ++--------- + 1 file changed, 2 insertions(+), 9 deletions(-) + +--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c +@@ -402,15 +402,8 @@ struct kfd_dev *kgd2kfd_probe(struct amd + f2g = &gfx_v11_kfd2kgd; + break; + case IP_VERSION(11, 0, 3): +- if ((adev->pdev->device == 0x7460 && +- adev->pdev->revision == 0x00) || +- (adev->pdev->device == 0x7461 && +- adev->pdev->revision == 0x00)) +- /* Note: Compiler version is 11.0.5 while HW version is 11.0.3 */ +- gfx_target_version = 110005; +- else +- /* Note: Compiler version is 11.0.1 while HW version is 11.0.3 */ +- gfx_target_version = 110001; ++ /* Note: Compiler version is 11.0.1 while HW version is 11.0.3 */ ++ gfx_target_version = 110001; + f2g = &gfx_v11_kfd2kgd; + break; + default: diff --git a/queue-6.6/series b/queue-6.6/series index 32af1003699..f38307aa980 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -54,3 +54,20 @@ mmc-sdhci-acpi-add-quirk-to-enable-pull-up-on-the-card-detect-gpio-on-asus-t100t drm-fbdev-generic-do-not-set-physical-framebuffer-address.patch fbdev-savage-handle-err-return-when-savagefb_check_var-failed.patch drm-amdgpu-atomfirmware-add-intergrated-info-v2.3-table.patch +9p-add-missing-locking-around-taking-dentry-fid-list.patch +drm-amd-fix-shutdown-again-on-some-smu-v13.0.4-11-platforms.patch +revert-drm-amdkfd-fix-gfx_target_version-for-certain-11.0.3-devices.patch +kvm-svm-warn-on-vnmi-nmi-window-iff-nmis-are-outright-masked.patch +kvm-arm64-fix-aarch32-register-narrowing-on-userspace-write.patch +kvm-arm64-allow-aarch32-pstate.m-to-be-restored-as-system-mode.patch +kvm-arm64-aarch32-fix-spurious-trapping-of-conditional-instructions.patch +loongarch-add-all-cpus-enabled-by-fdt-to-numa-node-0.patch +loongarch-override-higher-address-bits-in-jump_virt_addr.patch +clk-bcm-dvp-assign-num-before-accessing-hws.patch +clk-bcm-rpi-assign-num-before-accessing-hws.patch +clk-qcom-clk-alpha-pll-fix-rate-setting-for-stromer-plls.patch +crypto-ecdsa-fix-module-auto-load-on-add-key.patch +crypto-ecrdsa-fix-module-auto-load-on-add_key.patch +crypto-qat-fix-adf_dev_reset_sync-memory-leak.patch +kbuild-remove-support-for-clang-s-thinlto-caching.patch +mm-fix-race-between-__split_huge_pmd_locked-and-gup-fast.patch