--- /dev/null
+From c898afdc15645efb555acb6d85b484eb40a45409 Mon Sep 17 00:00:00 2001
+From: Dominique Martinet <asmadeus@codewreck.org>
+Date: Tue, 21 May 2024 21:13:36 +0900
+Subject: 9p: add missing locking around taking dentry fid list
+
+From: Dominique Martinet <asmadeus@codewreck.org>
+
+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 <linux_oss@crudebyte.com>
+Message-ID: <20240521122947.1080227-1-asmadeus@codewreck.org>
+Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From 9368cdf90f52a68120d039887ccff74ff33b4444 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Thu, 25 Apr 2024 09:55:51 -0700
+Subject: clk: bcm: dvp: Assign ->num before accessing ->hws
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+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 <nathan@kernel.org>
+Link: https://lore.kernel.org/r/20240425-cbl-bcm-assign-counted-by-val-before-access-v1-1-e2db3b82d5ef@kernel.org
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/bcm/clk-bcm2711-dvp.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- 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
+ 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
+ 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)
--- /dev/null
+From 6dc445c1905096b2ed4db1a84570375b4e00cc0f Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Thu, 25 Apr 2024 09:55:52 -0700
+Subject: clk: bcm: rpi: Assign ->num before accessing ->hws
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+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 <nathan@kernel.org>
+Link: https://lore.kernel.org/r/20240425-cbl-bcm-assign-counted-by-val-before-access-v1-2-e2db3b82d5ef@kernel.org
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/bcm/clk-raspberrypi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/clk/bcm/clk-raspberrypi.c
++++ b/drivers/clk/bcm/clk-raspberrypi.c
+@@ -371,8 +371,8 @@ static int raspberrypi_discover_clocks(s
+ if (IS_ERR(hw))
+ return PTR_ERR(hw);
+
+- data->hws[clks->id] = hw;
+ data->num = clks->id + 1;
++ data->hws[clks->id] = hw;
+ }
+
+ clks++;
--- /dev/null
+From 5fce38e2a1a97900989d9fedebcf5a4dacdaee30 Mon Sep 17 00:00:00 2001
+From: Gabor Juhos <j4g8y7@gmail.com>
+Date: Fri, 15 Mar 2024 17:16:41 +0100
+Subject: clk: qcom: apss-ipq-pll: use stromer ops for IPQ5018 to fix boot failure
+
+From: Gabor Juhos <j4g8y7@gmail.com>
+
+commit 5fce38e2a1a97900989d9fedebcf5a4dacdaee30 upstream.
+
+Booting v6.8 results in a hang on various IPQ5018 based boards.
+Investigating the problem showed that the hang happens when the
+clk_alpha_pll_stromer_plus_set_rate() function tries to write
+into the PLL_MODE register of the APSS PLL.
+
+Checking the downstream code revealed that it uses [1] stromer
+specific operations for IPQ5018, whereas in the current code
+the stromer plus specific operations are used.
+
+The ops in the 'ipq_pll_stromer_plus' clock definition can't be
+changed since that is needed for IPQ5332, so add a new alpha pll
+clock declaration which uses the correct stromer ops and use this
+new clock for IPQ5018 to avoid the boot failure.
+
+Also, change pll_type in 'ipq5018_pll_data' to
+CLK_ALPHA_PLL_TYPE_STROMER to better reflect that it is a Stromer
+PLL and change the apss_ipq_pll_probe() function accordingly.
+
+1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4/drivers/clk/qcom/apss-ipq5018.c#L67
+
+Cc: stable@vger.kernel.org
+Fixes: 50492f929486 ("clk: qcom: apss-ipq-pll: add support for IPQ5018")
+Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
+Tested-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
+Reviewed-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
+Link: https://lore.kernel.org/r/20240315-apss-ipq-pll-ipq5018-hang-v2-1-6fe30ada2009@gmail.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/qcom/apss-ipq-pll.c | 30 +++++++++++++++++++++++++++---
+ 1 file changed, 27 insertions(+), 3 deletions(-)
+
+--- a/drivers/clk/qcom/apss-ipq-pll.c
++++ b/drivers/clk/qcom/apss-ipq-pll.c
+@@ -55,6 +55,29 @@ static struct clk_alpha_pll ipq_pll_huay
+ },
+ };
+
++static struct clk_alpha_pll ipq_pll_stromer = {
++ .offset = 0x0,
++ /*
++ * Reuse CLK_ALPHA_PLL_TYPE_STROMER_PLUS register offsets.
++ * Although this is a bit confusing, but the offset values
++ * are correct nevertheless.
++ */
++ .regs = ipq_pll_offsets[CLK_ALPHA_PLL_TYPE_STROMER_PLUS],
++ .flags = SUPPORTS_DYNAMIC_UPDATE,
++ .clkr = {
++ .enable_reg = 0x0,
++ .enable_mask = BIT(0),
++ .hw.init = &(const struct clk_init_data) {
++ .name = "a53pll",
++ .parent_data = &(const struct clk_parent_data) {
++ .fw_name = "xo",
++ },
++ .num_parents = 1,
++ .ops = &clk_alpha_pll_stromer_ops,
++ },
++ },
++};
++
+ static struct clk_alpha_pll ipq_pll_stromer_plus = {
+ .offset = 0x0,
+ .regs = ipq_pll_offsets[CLK_ALPHA_PLL_TYPE_STROMER_PLUS],
+@@ -145,8 +168,8 @@ struct apss_pll_data {
+ };
+
+ static const struct apss_pll_data ipq5018_pll_data = {
+- .pll_type = CLK_ALPHA_PLL_TYPE_STROMER_PLUS,
+- .pll = &ipq_pll_stromer_plus,
++ .pll_type = CLK_ALPHA_PLL_TYPE_STROMER,
++ .pll = &ipq_pll_stromer,
+ .pll_config = &ipq5018_pll_config,
+ };
+
+@@ -204,7 +227,8 @@ static int apss_ipq_pll_probe(struct pla
+
+ if (data->pll_type == CLK_ALPHA_PLL_TYPE_HUAYRA)
+ clk_alpha_pll_configure(data->pll, regmap, data->pll_config);
+- else if (data->pll_type == CLK_ALPHA_PLL_TYPE_STROMER_PLUS)
++ else if (data->pll_type == CLK_ALPHA_PLL_TYPE_STROMER ||
++ data->pll_type == CLK_ALPHA_PLL_TYPE_STROMER_PLUS)
+ clk_stromer_pll_configure(data->pll, regmap, data->pll_config);
+
+ ret = devm_clk_register_regmap(dev, &data->pll->clkr);
--- /dev/null
+From 3c5b3e17b8fd1f1add5a9477306c355fab126977 Mon Sep 17 00:00:00 2001
+From: Gabor Juhos <j4g8y7@gmail.com>
+Date: Thu, 28 Mar 2024 08:54:31 +0100
+Subject: clk: qcom: clk-alpha-pll: fix rate setting for Stromer PLLs
+
+From: Gabor Juhos <j4g8y7@gmail.com>
+
+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 <dmitry.baryshkov@linaro.org>
+Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
+Link: https://lore.kernel.org/r/20240328-alpha-pll-fix-stromer-set-rate-v3-1-1b79714c78bc@gmail.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -2489,6 +2489,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);
--- /dev/null
+From 48e4fd6d54f54d0ceab5a952d73e47a9454a6ccb Mon Sep 17 00:00:00 2001
+From: Stefan Berger <stefanb@linux.ibm.com>
+Date: Thu, 21 Mar 2024 10:44:33 -0400
+Subject: crypto: ecdsa - Fix module auto-load on add-key
+
+From: Stefan Berger <stefanb@linux.ibm.com>
+
+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 <stefanb@linux.ibm.com>
+Reviewed-by: Vitaly Chikunov <vt@altlinux.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <stefanb@linux.ibm.com>");
+ 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");
--- /dev/null
+From eb5739a1efbc9ff216271aeea0ebe1c92e5383e5 Mon Sep 17 00:00:00 2001
+From: Vitaly Chikunov <vt@altlinux.org>
+Date: Mon, 18 Mar 2024 03:42:40 +0300
+Subject: crypto: ecrdsa - Fix module auto-load on add_key
+
+From: Vitaly Chikunov <vt@altlinux.org>
+
+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 <<EOF
+ MIIB/DCCAWagAwIBAgIUK8+whWevr3FFkSdU9GLDAM7ure8wDAYIKoUDBwEBAwMFADARMQ8wDQYD
+ VQQDDAZDQSBLZXkwIBcNMjIwMjAxMjIwOTQxWhgPMjA4MjEyMDUyMjA5NDFaMBExDzANBgNVBAMM
+ BkNBIEtleTCBoDAXBggqhQMHAQEBAjALBgkqhQMHAQIBAgEDgYQABIGALXNrTJGgeErBUOov3Cfo
+ IrHF9fcj8UjzwGeKCkbCcINzVUbdPmCopeJRHDJEvQBX1CQUPtlwDv6ANjTTRoq5nCk9L5PPFP1H
+ z73JIXHT0eRBDVoWy0cWDRz1mmQlCnN2HThMtEloaQI81nTlKZOcEYDtDpi5WODmjEeRNQJMdqCj
+ UDBOMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFCwfOITMbE9VisW1i2TYeu1tAo5QMB8GA1UdIwQY
+ MBaAFCwfOITMbE9VisW1i2TYeu1tAo5QMAwGCCqFAwcBAQMDBQADgYEAmBfJCMTdC0/NSjz4BBiQ
+ qDIEjomO7FEHYlkX5NGulcF8FaJW2jeyyXXtbpnub1IQ8af1KFIpwoS2e93LaaofxpWlpQLlju6m
+ KYLOcO4xK3Whwa2hBAz9YbpUSFjvxnkS2/jpH2MsOSXuUEeCruG/RkHHB3ACef9umG6HCNQuAPY=
+ EOF
+
+2. Optionally, trace module requests with: trace-cmd stream -e module &
+
+3. Trigger add_key call for the cert:
+
+ # keyctl padd asymmetric "" @u <test-gost2012_512-A.cer
+ 939910969
+ # lsmod | head -3
+ Module Size Used by
+ ecrdsa_generic 16384 0
+ streebog_generic 28672 0
+
+Repored-by: Paul Wolneykien <manowar@altlinux.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
+Tested-by: Stefan Berger <stefanb@linux.ibm.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <vt@altlinux.org>");
+ MODULE_DESCRIPTION("EC-RDSA generic algorithm");
++MODULE_ALIAS_CRYPTO("ecrdsa");
+ MODULE_ALIAS_CRYPTO("ecrdsa-generic");
--- /dev/null
+From d3b17c6d9dddc2db3670bc9be628b122416a3d26 Mon Sep 17 00:00:00 2001
+From: Herbert Xu <herbert@gondor.apana.org.au>
+Date: Wed, 8 May 2024 16:39:51 +0800
+Subject: crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak
+
+From: Herbert Xu <herbert@gondor.apana.org.au>
+
+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: <stable@vger.kernel.org> #6.8+
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -130,8 +130,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;
+@@ -147,16 +146,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);
+@@ -191,10 +182,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;
--- /dev/null
+From 267cace556e8a53d703119f7435ab556209e5b6a Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+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 <mario.limonciello@amd.com>
+
+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 <electrodexsnet@gmail.com>
+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 <Tim.Huang@amd.com>
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From aba091547ef6159d52471f42a3ef531b7b660ed8 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+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 <nathan@kernel.org>
+
+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 <elsk@google.com>
+Closes: https://github.com/ClangBuiltLinux/linux/issues/2021
+Reported-by: Masami Hiramatsu <mhiramat@kernel.org>
+Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.org/
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Makefile | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/Makefile
++++ b/Makefile
+@@ -942,7 +942,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
+@@ -1477,7 +1476,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'
+@@ -1783,7 +1782,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
--- /dev/null
+From c92e8b9eacebb4060634ebd9395bba1b29aadc68 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Fri, 24 May 2024 15:19:56 +0100
+Subject: KVM: arm64: AArch32: Fix spurious trapping of conditional instructions
+
+From: Marc Zyngier <maz@kernel.org>
+
+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 <oliver.upton@linux.dev>
+Link: https://lore.kernel.org/r/20240524141956.1450304-4-maz@kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From dfe6d190f38fc5df5ff2614b463a5195a399c885 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+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 <maz@kernel.org>
+
+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 <oliver.upton@linux.dev>
+Link: https://lore.kernel.org/r/20240524141956.1450304-3-maz@kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 947051e361d551e0590777080ffc4926190f62f2 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Fri, 24 May 2024 15:19:54 +0100
+Subject: KVM: arm64: Fix AArch32 register narrowing on userspace write
+
+From: Marc Zyngier <maz@kernel.org>
+
+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 <nsg@linux.ibm.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
+Acked-by: Oliver Upton <oliver.upton@linux.dev>
+Link: https://lore.kernel.org/r/20240524141956.1450304-2-maz@kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.
--- /dev/null
+From b4bd556467477420ee3a91fbcba73c579669edc6 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+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 <seanjc@google.com>
+
+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 <Santosh.Shukla@amd.com>
+Cc: Maxim Levitsky <mlevitsk@redhat.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-ID: <20240522021435.1684366-1-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -3843,16 +3843,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
--- /dev/null
+From 3de9c42d02a79a5e09bbee7a4421ddc00cfd5c6d Mon Sep 17 00:00:00 2001
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Date: Mon, 3 Jun 2024 15:45:53 +0800
+Subject: LoongArch: Add all CPUs enabled by fdt to NUMA node 0
+
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+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 <jiaxun.yang@flygoat.com>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+@@ -456,6 +458,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) {
--- /dev/null
+From b56f67a6c748bb009f313f91651c8020d2338d63 Mon Sep 17 00:00:00 2001
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Date: Mon, 3 Jun 2024 15:45:53 +0800
+Subject: LoongArch: Fix built-in DTB detection
+
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+commit b56f67a6c748bb009f313f91651c8020d2338d63 upstream.
+
+fdt_check_header(__dtb_start) will always success because kernel
+provides a dummy dtb, and by coincidence __dtb_start clashed with
+entry of this dummy dtb. The consequence is fdt passed from firmware
+will never be taken.
+
+Fix by trying to utilise __dtb_start only when CONFIG_BUILTIN_DTB is
+enabled.
+
+Cc: stable@vger.kernel.org
+Fixes: 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware")
+Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kernel/setup.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
+index 89ad756aeeed..3d048f1be143 100644
+--- a/arch/loongarch/kernel/setup.c
++++ b/arch/loongarch/kernel/setup.c
+@@ -282,7 +282,7 @@ static void __init fdt_setup(void)
+ return;
+
+ /* Prefer to use built-in dtb, checking its legality first. */
+- if (!fdt_check_header(__dtb_start))
++ if (IS_ENABLED(CONFIG_BUILTIN_DTB) && !fdt_check_header(__dtb_start))
+ fdt_pointer = __dtb_start;
+ else
+ fdt_pointer = efi_fdt_pointer(); /* Fallback to firmware dtb */
+--
+2.45.2
+
--- /dev/null
+From beb2800074c15362cf9f6c7301120910046d6556 Mon Sep 17 00:00:00 2001
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Date: Mon, 3 Jun 2024 15:45:53 +0800
+Subject: LoongArch: Fix entry point in kernel image header
+
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+commit beb2800074c15362cf9f6c7301120910046d6556 upstream.
+
+Currently kernel entry in head.S is in DMW address range, firmware is
+instructed to jump to this address after loading the kernel image.
+
+However kernel should not make any assumption on firmware's DMW
+setting, thus the entry point should be a physical address falls into
+direct translation region.
+
+Fix by converting entry address to physical and amend entry calculation
+logic in libstub accordingly.
+
+BTW, use ABSOLUTE() to calculate variables to make Clang/LLVM happy.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kernel/head.S | 2 +-
+ arch/loongarch/kernel/vmlinux.lds.S | 10 ++++++----
+ drivers/firmware/efi/libstub/loongarch.c | 2 +-
+ 3 files changed, 8 insertions(+), 6 deletions(-)
+
+--- a/arch/loongarch/kernel/head.S
++++ b/arch/loongarch/kernel/head.S
+@@ -22,7 +22,7 @@
+ _head:
+ .word MZ_MAGIC /* "MZ", MS-DOS header */
+ .org 0x8
+- .dword kernel_entry /* Kernel entry point */
++ .dword _kernel_entry /* Kernel entry point (physical address) */
+ .dword _kernel_asize /* Kernel image effective size */
+ .quad PHYS_LINK_KADDR /* Kernel image load offset from start of RAM */
+ .org 0x38 /* 0x20 ~ 0x37 reserved */
+--- a/arch/loongarch/kernel/vmlinux.lds.S
++++ b/arch/loongarch/kernel/vmlinux.lds.S
+@@ -6,6 +6,7 @@
+
+ #define PAGE_SIZE _PAGE_SIZE
+ #define RO_EXCEPTION_TABLE_ALIGN 4
++#define PHYSADDR_MASK 0xffffffffffff /* 48-bit */
+
+ /*
+ * Put .bss..swapper_pg_dir as the first thing in .bss. This will
+@@ -142,10 +143,11 @@ SECTIONS
+
+ #ifdef CONFIG_EFI_STUB
+ /* header symbols */
+- _kernel_asize = _end - _text;
+- _kernel_fsize = _edata - _text;
+- _kernel_vsize = _end - __initdata_begin;
+- _kernel_rsize = _edata - __initdata_begin;
++ _kernel_entry = ABSOLUTE(kernel_entry & PHYSADDR_MASK);
++ _kernel_asize = ABSOLUTE(_end - _text);
++ _kernel_fsize = ABSOLUTE(_edata - _text);
++ _kernel_vsize = ABSOLUTE(_end - __initdata_begin);
++ _kernel_rsize = ABSOLUTE(_edata - __initdata_begin);
+ #endif
+
+ .gptab.sdata : {
+--- a/drivers/firmware/efi/libstub/loongarch.c
++++ b/drivers/firmware/efi/libstub/loongarch.c
+@@ -41,7 +41,7 @@ static efi_status_t exit_boot_func(struc
+ unsigned long __weak kernel_entry_address(unsigned long kernel_addr,
+ efi_loaded_image_t *image)
+ {
+- return *(unsigned long *)(kernel_addr + 8) - VMLINUX_LOAD_ADDRESS + kernel_addr;
++ return *(unsigned long *)(kernel_addr + 8) - PHYSADDR(VMLINUX_LOAD_ADDRESS) + kernel_addr;
+ }
+
+ efi_status_t efi_boot_kernel(void *handle, efi_loaded_image_t *image,
--- /dev/null
+From 1098efd299ffe9c8af818425338c7f6c4f930a98 Mon Sep 17 00:00:00 2001
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Date: Mon, 3 Jun 2024 15:45:53 +0800
+Subject: LoongArch: Override higher address bits in JUMP_VIRT_ADDR
+
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+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 <jiaxun.yang@flygoat.com>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -42,7 +42,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
+
--- /dev/null
+From 3a5a8d343e1cf96eb9971b17cbd4b832ab19b8e7 Mon Sep 17 00:00:00 2001
+From: Ryan Roberts <ryan.roberts@arm.com>
+Date: Wed, 1 May 2024 15:33:10 +0100
+Subject: mm: fix race between __split_huge_pmd_locked() and GUP-fast
+
+From: Ryan Roberts <ryan.roberts@arm.com>
+
+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 <ryan.roberts@arm.com>
+Reviewed-by: Zi Yan <ziy@nvidia.com>
+Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: Andreas Larsson <andreas@gaisler.com>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
+Cc: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
+Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
+Cc: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: "David S. Miller" <davem@davemloft.net>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Jonathan Corbet <corbet@lwn.net>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
+Cc: Nicholas Piggin <npiggin@gmail.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Sven Schnelle <svens@linux.ibm.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Will Deacon <will@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -140,7 +140,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 |
+ +---------------------------+--------------------------------------------------+
+@@ -196,7 +197,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
+@@ -1778,8 +1778,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
+@@ -631,6 +631,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
+@@ -2493,32 +2493,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);
+@@ -2529,6 +2508,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);
+ folio = page_folio(page);
+ if (pmd_dirty(old_pmd)) {
+--- 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
--- /dev/null
+From dd2b75fd9a79bf418e088656822af06fc253dbe3 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+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 <alexander.deucher@amd.com>
+
+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 <Feifei.Xu@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: Feifei Xu <feifei.xu@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -408,15 +408,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;
+ case IP_VERSION(11, 5, 0):
fbdev-savage-handle-err-return-when-savagefb_check_var-failed.patch
firmware-qcom_scm-disable-clocks-if-qcom_scm_bw_enable-fails.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-fix-built-in-dtb-detection.patch
+loongarch-override-higher-address-bits-in-jump_virt_addr.patch
+loongarch-fix-entry-point-in-kernel-image-header.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
+clk-qcom-apss-ipq-pll-use-stromer-ops-for-ipq5018-to-fix-boot-failure.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
projects / thirdparty / kernel / stable-queue.git / commitdiff
