--- /dev/null
+From 711aad3c43a9853657e00225466d204e46ae528b Mon Sep 17 00:00:00 2001
+From: Sebastian Wiese-Wagner <seb@fastmail.to>
+Date: Mon, 20 Jan 2025 19:12:40 +0100
+Subject: ALSA: hda/realtek: Enable Mute LED on HP Laptop 14s-fq1xxx
+
+From: Sebastian Wiese-Wagner <seb@fastmail.to>
+
+commit 711aad3c43a9853657e00225466d204e46ae528b upstream.
+
+This HP Laptop uses ALC236 codec with COEF 0x07 controlling the mute
+LED. Enable existing quirk for this device.
+
+Signed-off-by: Sebastian Wiese-Wagner <seb@fastmail.to>
+Cc: <stable@vger.kernel.org>
+Link: https://patch.msgid.link/20250120181240.13106-1-seb@fastmail.to
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -9949,6 +9949,7 @@ static const struct hda_quirk alc269_fix
+ SND_PCI_QUIRK(0x103c, 0x8870, "HP ZBook Fury 15.6 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT),
+ SND_PCI_QUIRK(0x103c, 0x8873, "HP ZBook Studio 15.6 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT),
+ SND_PCI_QUIRK(0x103c, 0x887a, "HP Laptop 15s-eq2xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
++ SND_PCI_QUIRK(0x103c, 0x887c, "HP Laptop 14s-fq1xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
+ SND_PCI_QUIRK(0x103c, 0x888a, "HP ENVY x360 Convertible 15-eu0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS),
+ SND_PCI_QUIRK(0x103c, 0x888d, "HP ZBook Power 15.6 inch G8 Mobile Workstation PC", ALC236_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8895, "HP EliteBook 855 G8 Notebook PC", ALC285_FIXUP_HP_SPEAKERS_MICMUTE_LED),
--- /dev/null
+From 9d241b06802c6c2176ae7aa4f9f17f8a577ed337 Mon Sep 17 00:00:00 2001
+From: Jakob Unterwurzacher <jakobunt@gmail.com>
+Date: Fri, 13 Dec 2024 10:54:58 +0100
+Subject: arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma
+
+From: Jakob Unterwurzacher <jakobunt@gmail.com>
+
+commit 9d241b06802c6c2176ae7aa4f9f17f8a577ed337 upstream.
+
+During mass manufacturing, we noticed the mmc_rx_crc_error counter,
+as reported by "ethtool -S eth0 | grep mmc_rx_crc_error", to increase
+above zero during nuttcp speedtests. Most of the time, this did not
+affect the achieved speed, but it prompted this investigation.
+
+Cycling through the rx_delay range on six boards (see table below) of
+various ages shows that there is a large good region from 0x12 to 0x35
+where we see zero crc errors on all tested boards.
+
+The old rx_delay value (0x10) seems to have always been on the edge for
+the KSZ9031RNX that is usually placed on Puma.
+
+Choose "rx_delay = 0x23" to put us smack in the middle of the good
+region. This works fine as well with the KSZ9131RNX PHY that was used
+for a small number of boards during the COVID chip shortages.
+
+ Board S/N PHY rx_delay good region
+ --------- --- --------------------
+ Puma TT0069903 KSZ9031RNX 0x11 0x35
+ Puma TT0157733 KSZ9031RNX 0x11 0x35
+ Puma TT0681551 KSZ9031RNX 0x12 0x37
+ Puma TT0681156 KSZ9031RNX 0x10 0x38
+ Puma 17496030079 KSZ9031RNX 0x10 0x37 (Puma v1.2 from 2017)
+ Puma TT0681720 KSZ9131RNX 0x02 0x39 (alternative PHY used in very few boards)
+
+ Intersection of good regions = 0x12 0x35
+ Middle of good region = 0x23
+
+Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
+Cc: stable@vger.kernel.org
+Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
+Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # Puma v2.1 and v2.3 with KSZ9031
+Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
+Link: https://lore.kernel.org/r/20241213-puma_rx_delay-v4-1-8e8e11cc6ed7@cherry.de
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+@@ -147,7 +147,7 @@
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x10>;
+- rx_delay = <0x10>;
++ rx_delay = <0x23>;
+ status = "okay";
+ };
+
--- /dev/null
+From 55cf2f4b945f6a6416cc2524ba740b83cc9af25a Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@linaro.org>
+Date: Wed, 4 Dec 2024 15:07:15 +0300
+Subject: binfmt_flat: Fix integer overflow bug on 32 bit systems
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+commit 55cf2f4b945f6a6416cc2524ba740b83cc9af25a upstream.
+
+Most of these sizes and counts are capped at 256MB so the math doesn't
+result in an integer overflow. The "relocs" count needs to be checked
+as well. Otherwise on 32bit systems the calculation of "full_data"
+could be wrong.
+
+ full_data = data_len + relocs * sizeof(unsigned long);
+
+Fixes: c995ee28d29d ("binfmt_flat: prevent kernel dammage from corrupted executable headers")
+Cc: stable@vger.kernel.org
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Acked-by: Nicolas Pitre <npitre@baylibre.com>
+Link: https://lore.kernel.org/r/5be17f6c-5338-43be-91ef-650153b975cb@stanley.mountain
+Signed-off-by: Kees Cook <kees@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/binfmt_flat.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/binfmt_flat.c
++++ b/fs/binfmt_flat.c
+@@ -478,7 +478,7 @@ static int load_flat_file(struct linux_b
+ * 28 bits (256 MB) is way more than reasonable in this case.
+ * If some top bits are set we have probable binary corruption.
+ */
+- if ((text_len | data_len | bss_len | stack_len | full_data) >> 28) {
++ if ((text_len | data_len | bss_len | stack_len | relocs | full_data) >> 28) {
+ pr_err("bad header\n");
+ ret = -ENOEXEC;
+ goto err;
--- /dev/null
+From 5c61419e02033eaf01733d66e2fcd4044808f482 Mon Sep 17 00:00:00 2001
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+Date: Wed, 29 Jan 2025 00:08:14 +0300
+Subject: Bluetooth: L2CAP: accept zero as a special value for MTU auto-selection
+
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+
+commit 5c61419e02033eaf01733d66e2fcd4044808f482 upstream.
+
+One of the possible ways to enable the input MTU auto-selection for L2CAP
+connections is supposed to be through passing a special "0" value for it
+as a socket option. Commit [1] added one of those into avdtp. However, it
+simply wouldn't work because the kernel still treats the specified value
+as invalid and denies the setting attempt. Recorded BlueZ logs include the
+following:
+
+ bluetoothd[496]: profiles/audio/avdtp.c:l2cap_connect() setsockopt(L2CAP_OPTIONS): Invalid argument (22)
+
+[1]: https://github.com/bluez/bluez/commit/ae5be371a9f53fed33d2b34748a95a5498fd4b77
+
+Found by Linux Verification Center (linuxtesting.org).
+
+Fixes: 4b6e228e297b ("Bluetooth: Auto tune if input MTU is set to 0")
+Cc: stable@vger.kernel.org
+Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/l2cap_sock.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/bluetooth/l2cap_sock.c
++++ b/net/bluetooth/l2cap_sock.c
+@@ -709,12 +709,12 @@ static bool l2cap_valid_mtu(struct l2cap
+ {
+ switch (chan->scid) {
+ case L2CAP_CID_ATT:
+- if (mtu < L2CAP_LE_MIN_MTU)
++ if (mtu && mtu < L2CAP_LE_MIN_MTU)
+ return false;
+ break;
+
+ default:
+- if (mtu < L2CAP_DEFAULT_MIN_MTU)
++ if (mtu && mtu < L2CAP_DEFAULT_MIN_MTU)
+ return false;
+ }
+
--- /dev/null
+From 5f397409f8ee5bc82901eeaf799e1cbc4f8edcf1 Mon Sep 17 00:00:00 2001
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+Date: Wed, 18 Dec 2024 00:19:59 +0300
+Subject: Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc
+
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+
+commit 5f397409f8ee5bc82901eeaf799e1cbc4f8edcf1 upstream.
+
+A NULL sock pointer is passed into l2cap_sock_alloc() when it is called
+from l2cap_sock_new_connection_cb() and the error handling paths should
+also be aware of it.
+
+Seemingly a more elegant solution would be to swap bt_sock_alloc() and
+l2cap_chan_create() calls since they are not interdependent to that moment
+but then l2cap_chan_create() adds the soon to be deallocated and still
+dummy-initialized channel to the global list accessible by many L2CAP
+paths. The channel would be removed from the list in short period of time
+but be a bit more straight-forward here and just check for NULL instead of
+changing the order of function calls.
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE static
+analysis tool.
+
+Fixes: 7c4f78cdb8e7 ("Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/l2cap_sock.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/bluetooth/l2cap_sock.c
++++ b/net/bluetooth/l2cap_sock.c
+@@ -1885,7 +1885,8 @@ static struct sock *l2cap_sock_alloc(str
+ chan = l2cap_chan_create();
+ if (!chan) {
+ sk_free(sk);
+- sock->sk = NULL;
++ if (sock)
++ sock->sk = NULL;
+ return NULL;
+ }
+
--- /dev/null
+From 43855ac61483cb914f060851535ea753c094b3e0 Mon Sep 17 00:00:00 2001
+From: Viresh Kumar <viresh.kumar@linaro.org>
+Date: Wed, 22 Jan 2025 11:36:16 +0530
+Subject: cpufreq: s3c64xx: Fix compilation warning
+
+From: Viresh Kumar <viresh.kumar@linaro.org>
+
+commit 43855ac61483cb914f060851535ea753c094b3e0 upstream.
+
+The driver generates following warning when regulator support isn't
+enabled in the kernel. Fix it.
+
+ drivers/cpufreq/s3c64xx-cpufreq.c: In function 's3c64xx_cpufreq_set_target':
+>> drivers/cpufreq/s3c64xx-cpufreq.c:55:22: warning: variable 'old_freq' set but not used [-Wunused-but-set-variable]
+ 55 | unsigned int old_freq, new_freq;
+ | ^~~~~~~~
+>> drivers/cpufreq/s3c64xx-cpufreq.c:54:30: warning: variable 'dvfs' set but not used [-Wunused-but-set-variable]
+ 54 | struct s3c64xx_dvfs *dvfs;
+ | ^~~~
+
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202501191803.CtfT7b2o-lkp@intel.com/
+Cc: 5.4+ <stable@vger.kernel.org> # v5.4+
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Link: https://patch.msgid.link/236b227e929e5adc04d1e9e7af6845a46c8e9432.1737525916.git.viresh.kumar@linaro.org
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/s3c64xx-cpufreq.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/cpufreq/s3c64xx-cpufreq.c
++++ b/drivers/cpufreq/s3c64xx-cpufreq.c
+@@ -24,6 +24,7 @@ struct s3c64xx_dvfs {
+ unsigned int vddarm_max;
+ };
+
++#ifdef CONFIG_REGULATOR
+ static struct s3c64xx_dvfs s3c64xx_dvfs_table[] = {
+ [0] = { 1000000, 1150000 },
+ [1] = { 1050000, 1150000 },
+@@ -31,6 +32,7 @@ static struct s3c64xx_dvfs s3c64xx_dvfs_
+ [3] = { 1200000, 1350000 },
+ [4] = { 1300000, 1350000 },
+ };
++#endif
+
+ static struct cpufreq_frequency_table s3c64xx_freq_table[] = {
+ { 0, 0, 66000 },
+@@ -51,15 +53,16 @@ static struct cpufreq_frequency_table s3
+ static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy,
+ unsigned int index)
+ {
+- struct s3c64xx_dvfs *dvfs;
+- unsigned int old_freq, new_freq;
++ unsigned int new_freq = s3c64xx_freq_table[index].frequency;
+ int ret;
+
++#ifdef CONFIG_REGULATOR
++ struct s3c64xx_dvfs *dvfs;
++ unsigned int old_freq;
++
+ old_freq = clk_get_rate(policy->clk) / 1000;
+- new_freq = s3c64xx_freq_table[index].frequency;
+ dvfs = &s3c64xx_dvfs_table[s3c64xx_freq_table[index].driver_data];
+
+-#ifdef CONFIG_REGULATOR
+ if (vddarm && new_freq > old_freq) {
+ ret = regulator_set_voltage(vddarm,
+ dvfs->vddarm_min,
--- /dev/null
+From 819bf6662b93a5a8b0c396d2c7e7fab6264c9808 Mon Sep 17 00:00:00 2001
+From: Lijo Lazar <lijo.lazar@amd.com>
+Date: Wed, 22 Jan 2025 09:12:41 +0530
+Subject: drm/amd/pm: Mark MM activity as unsupported
+
+From: Lijo Lazar <lijo.lazar@amd.com>
+
+commit 819bf6662b93a5a8b0c396d2c7e7fab6264c9808 upstream.
+
+Aldebaran doesn't support querying MM activity percentage. Keep the
+field as 0xFFs to mark it as unsupported.
+
+Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+@@ -1752,7 +1752,6 @@ static ssize_t aldebaran_get_gpu_metrics
+
+ gpu_metrics->average_gfx_activity = metrics.AverageGfxActivity;
+ gpu_metrics->average_umc_activity = metrics.AverageUclkActivity;
+- gpu_metrics->average_mm_activity = 0;
+
+ /* Valid power data is available only from primary die */
+ if (aldebaran_is_primary(smu)) {
--- /dev/null
+From 9078a5bfa21e78ae68b6d7c365d1b92f26720c55 Mon Sep 17 00:00:00 2001
+From: Prike Liang <Prike.Liang@amd.com>
+Date: Tue, 14 Jan 2025 11:20:17 +0800
+Subject: drm/amdkfd: only flush the validate MES contex
+
+From: Prike Liang <Prike.Liang@amd.com>
+
+commit 9078a5bfa21e78ae68b6d7c365d1b92f26720c55 upstream.
+
+The following page fault was observed duringthe KFD process release.
+In this particular error case, the HIP test (./MemcpyPerformance -h)
+does not require the queue. As a result, the process_context_addr was
+not assigned when the KFD process was released, ultimately leading to
+this page fault during the execution of the function
+kfd_process_dequeue_from_all_devices().
+
+[345962.294891] amdgpu 0000:03:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:153 vmid:0 pasid:0)
+[345962.295333] amdgpu 0000:03:00.0: amdgpu: in page starting at address 0x0000000000000000 from client 10
+[345962.295775] amdgpu 0000:03:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000B33
+[345962.296097] amdgpu 0000:03:00.0: amdgpu: Faulty UTCL2 client ID: CPC (0x5)
+[345962.296394] amdgpu 0000:03:00.0: amdgpu: MORE_FAULTS: 0x1
+[345962.296633] amdgpu 0000:03:00.0: amdgpu: WALKER_ERROR: 0x1
+[345962.296876] amdgpu 0000:03:00.0: amdgpu: PERMISSION_FAULTS: 0x3
+[345962.297135] amdgpu 0000:03:00.0: amdgpu: MAPPING_ERROR: 0x1
+[345962.297377] amdgpu 0000:03:00.0: amdgpu: RW: 0x0
+[345962.297682] amdgpu 0000:03:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:169 vmid:0 pasid:0)
+
+Signed-off-by: Prike Liang <Prike.Liang@amd.com>
+Reviewed-by: Jonathan Kim <jonathan.kim@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
++++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
+@@ -86,9 +86,12 @@ void kfd_process_dequeue_from_device(str
+
+ if (pdd->already_dequeued)
+ return;
+-
++ /* The MES context flush needs to filter out the case which the
++ * KFD process is created without setting up the MES context and
++ * queue for creating a compute queue.
++ */
+ dev->dqm->ops.process_termination(dev->dqm, &pdd->qpd);
+- if (dev->kfd->shared_resources.enable_mes &&
++ if (dev->kfd->shared_resources.enable_mes && !!pdd->proc_ctx_gpu_addr &&
+ down_read_trylock(&dev->adev->reset_domain->sem)) {
+ amdgpu_mes_flush_shader_debugger(dev->adev,
+ pdd->proc_ctx_gpu_addr);
--- /dev/null
+From c7b49506b3ba7a62335e6f666a43f67d5cd9fd1e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Wed, 18 Dec 2024 19:36:47 +0200
+Subject: drm/i915: Drop 64bpp YUV formats from ICL+ SDR planes
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit c7b49506b3ba7a62335e6f666a43f67d5cd9fd1e upstream.
+
+I'm seeing underruns with these 64bpp YUV formats on TGL.
+
+The weird details:
+- only happens on pipe B/C/D SDR planes, pipe A SDR planes
+ seem fine, as do all HDR planes
+- somehow CDCLK related, higher CDCLK allows for bigger plane
+ with these formats without underruns. With 300MHz CDCLK I
+ can only go up to 1200 pixels wide or so, with 650MHz even
+ a 3840 pixel wide plane was OK
+- ICL and ADL so far appear unaffected
+
+So not really sure what's the deal with this, but bspec does
+state "64-bit formats supported only on the HDR planes" so
+let's just drop these formats from the SDR planes. We already
+disallow 64bpp RGB formats.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20241218173650.19782-2-ville.syrjala@linux.intel.com
+Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
+(cherry picked from commit 35e1aacfe536d6e8d8d440cd7155366da2541ad4)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
++++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
+@@ -102,8 +102,6 @@ static const u32 icl_sdr_y_plane_formats
+ DRM_FORMAT_Y216,
+ DRM_FORMAT_XYUV8888,
+ DRM_FORMAT_XVYU2101010,
+- DRM_FORMAT_XVYU12_16161616,
+- DRM_FORMAT_XVYU16161616,
+ };
+
+ static const u32 icl_sdr_uv_plane_formats[] = {
+@@ -130,8 +128,6 @@ static const u32 icl_sdr_uv_plane_format
+ DRM_FORMAT_Y216,
+ DRM_FORMAT_XYUV8888,
+ DRM_FORMAT_XVYU2101010,
+- DRM_FORMAT_XVYU12_16161616,
+- DRM_FORMAT_XVYU16161616,
+ };
+
+ static const u32 icl_hdr_plane_formats[] = {
--- /dev/null
+From fa6182c8b13ebfdc70ebdc09161a70dd8131f3b1 Mon Sep 17 00:00:00 2001
+From: Brian Geffon <bgeffon@google.com>
+Date: Mon, 27 Jan 2025 15:43:32 -0500
+Subject: drm/i915: Fix page cleanup on DMA remap failure
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Brian Geffon <bgeffon@google.com>
+
+commit fa6182c8b13ebfdc70ebdc09161a70dd8131f3b1 upstream.
+
+When converting to folios the cleanup path of shmem_get_pages() was
+missed. When a DMA remap fails and the max segment size is greater than
+PAGE_SIZE it will attempt to retry the remap with a PAGE_SIZEd segment
+size. The cleanup code isn't properly using the folio apis and as a
+result isn't handling compound pages correctly.
+
+v2 -> v3:
+(Ville) Just use shmem_sg_free_table() as-is in the failure path of
+shmem_get_pages(). shmem_sg_free_table() will clear mapping unevictable
+but it will be reset when it retries in shmem_sg_alloc_table().
+
+v1 -> v2:
+(Ville) Fixed locations where we were not clearing mapping unevictable.
+
+Cc: stable@vger.kernel.org
+Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
+Cc: Vidya Srinivas <vidya.srinivas@intel.com>
+Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13487
+Link: https://lore.kernel.org/lkml/20250116135636.410164-1-bgeffon@google.com/
+Fixes: 0b62af28f249 ("i915: convert shmem_sg_free_table() to use a folio_batch")
+Signed-off-by: Brian Geffon <bgeffon@google.com>
+Suggested-by: Tomasz Figa <tfiga@google.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20250127204332.336665-1-bgeffon@google.com
+Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
+Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+(cherry picked from commit 9e304a18630875352636ad52a3d2af47c3bde824)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+index fe69f2c8527d..ae3343c81a64 100644
+--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
++++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+@@ -209,8 +209,6 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
+ struct address_space *mapping = obj->base.filp->f_mapping;
+ unsigned int max_segment = i915_sg_segment_size(i915->drm.dev);
+ struct sg_table *st;
+- struct sgt_iter sgt_iter;
+- struct page *page;
+ int ret;
+
+ /*
+@@ -239,9 +237,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
+ * for PAGE_SIZE chunks instead may be helpful.
+ */
+ if (max_segment > PAGE_SIZE) {
+- for_each_sgt_page(page, sgt_iter, st)
+- put_page(page);
+- sg_free_table(st);
++ shmem_sg_free_table(st, mapping, false, false);
+ kfree(st);
+
+ max_segment = PAGE_SIZE;
+--
+2.48.1
+
--- /dev/null
+From 57965269896313e1629a518d3971ad55f599b792 Mon Sep 17 00:00:00 2001
+From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
+Date: Tue, 14 Jan 2025 16:13:34 -0800
+Subject: drm/i915/guc: Debug print LRC state entries only if the context is pinned
+
+From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
+
+commit 57965269896313e1629a518d3971ad55f599b792 upstream.
+
+After the context is unpinned the backing memory can also be unpinned,
+so any accesses via the lrc_reg_state pointer can end up in unmapped
+memory. To avoid that, make sure to only access that memory if the
+context is pinned when printing its info.
+
+v2: fix newline alignment
+
+Fixes: 28ff6520a34d ("drm/i915/guc: Update GuC debugfs to support new GuC")
+Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
+Cc: John Harrison <John.C.Harrison@Intel.com>
+Cc: Matthew Brost <matthew.brost@intel.com>
+Cc: <stable@vger.kernel.org> # v5.15+
+Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20250115001334.3875347-1-daniele.ceraolospurio@intel.com
+(cherry picked from commit 5bea40687c5cf2a33bf04e9110eb2e2b80222ef5)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 20 ++++++++++++++------
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
++++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+@@ -5154,12 +5154,20 @@ static inline void guc_log_context(struc
+ {
+ drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id.id);
+ drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
+- drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
+- ce->ring->head,
+- ce->lrc_reg_state[CTX_RING_HEAD]);
+- drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
+- ce->ring->tail,
+- ce->lrc_reg_state[CTX_RING_TAIL]);
++ if (intel_context_pin_if_active(ce)) {
++ drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
++ ce->ring->head,
++ ce->lrc_reg_state[CTX_RING_HEAD]);
++ drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
++ ce->ring->tail,
++ ce->lrc_reg_state[CTX_RING_TAIL]);
++ intel_context_unpin(ce);
++ } else {
++ drm_printf(p, "\t\tLRC Head: Internal %u, Memory not pinned\n",
++ ce->ring->head);
++ drm_printf(p, "\t\tLRC Tail: Internal %u, Memory not pinned\n",
++ ce->ring->tail);
++ }
+ drm_printf(p, "\t\tContext Pin Count: %u\n",
+ atomic_read(&ce->pin_count));
+ drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
--- /dev/null
+From 79fc672a092d93a7eac24fe20a571d4efd8fa5a4 Mon Sep 17 00:00:00 2001
+From: Haoxiang Li <haoxiang_li2024@163.com>
+Date: Thu, 19 Dec 2024 17:02:56 +0800
+Subject: drm/komeda: Add check for komeda_get_layer_fourcc_list()
+
+From: Haoxiang Li <haoxiang_li2024@163.com>
+
+commit 79fc672a092d93a7eac24fe20a571d4efd8fa5a4 upstream.
+
+Add check for the return value of komeda_get_layer_fourcc_list()
+to catch the potential exception.
+
+Fixes: 5d51f6c0da1b ("drm/komeda: Add writeback support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
+Acked-by: Liviu Dudau <liviu.dudau@arm.com>
+Link: https://lore.kernel.org/r/20241219090256.146424-1-haoxiang_li2024@163.com
+Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
++++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+@@ -160,6 +160,10 @@ static int komeda_wb_connector_add(struc
+ formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
+ kwb_conn->wb_layer->layer_type,
+ &n_formats);
++ if (!formats) {
++ kfree(kwb_conn);
++ return -ENOMEM;
++ }
+
+ err = drm_writeback_connector_init(&kms->base, wb_conn,
+ &komeda_wb_connector_funcs,
--- /dev/null
+From f4a9dd57e549a17a7dac1c1defec26abd7e5c2d4 Mon Sep 17 00:00:00 2001
+From: Maarten Lankhorst <dev@lankhorst.se>
+Date: Thu, 16 Jan 2025 15:28:24 +0100
+Subject: drm/modeset: Handle tiled displays in pan_display_atomic.
+
+From: Maarten Lankhorst <dev@lankhorst.se>
+
+commit f4a9dd57e549a17a7dac1c1defec26abd7e5c2d4 upstream.
+
+Tiled displays have a different x/y offset to begin with. Instead of
+attempting to remember this, just apply a delta instead.
+
+This fixes the first tile being duplicated on other tiles when vt
+switching.
+
+Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20250116142825.3933-1-dev@lankhorst.se
+Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_fb_helper.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/drm_fb_helper.c
++++ b/drivers/gpu/drm/drm_fb_helper.c
+@@ -1361,14 +1361,14 @@ int drm_fb_helper_set_par(struct fb_info
+ }
+ EXPORT_SYMBOL(drm_fb_helper_set_par);
+
+-static void pan_set(struct drm_fb_helper *fb_helper, int x, int y)
++static void pan_set(struct drm_fb_helper *fb_helper, int dx, int dy)
+ {
+ struct drm_mode_set *mode_set;
+
+ mutex_lock(&fb_helper->client.modeset_mutex);
+ drm_client_for_each_modeset(mode_set, &fb_helper->client) {
+- mode_set->x = x;
+- mode_set->y = y;
++ mode_set->x += dx;
++ mode_set->y += dy;
+ }
+ mutex_unlock(&fb_helper->client.modeset_mutex);
+ }
+@@ -1377,16 +1377,18 @@ static int pan_display_atomic(struct fb_
+ struct fb_info *info)
+ {
+ struct drm_fb_helper *fb_helper = info->par;
+- int ret;
++ int ret, dx, dy;
+
+- pan_set(fb_helper, var->xoffset, var->yoffset);
++ dx = var->xoffset - info->var.xoffset;
++ dy = var->yoffset - info->var.yoffset;
++ pan_set(fb_helper, dx, dy);
+
+ ret = drm_client_modeset_commit_locked(&fb_helper->client);
+ if (!ret) {
+ info->var.xoffset = var->xoffset;
+ info->var.yoffset = var->yoffset;
+ } else
+- pan_set(fb_helper, info->var.xoffset, info->var.yoffset);
++ pan_set(fb_helper, -dx, -dy);
+
+ return ret;
+ }
--- /dev/null
+From 666e1960464140cc4bc9203c203097e70b54c95a Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Tue, 5 Nov 2024 14:38:16 +0100
+Subject: drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit 666e1960464140cc4bc9203c203097e70b54c95a upstream.
+
+The code for detecting and updating the connector status in
+cdn_dp_pd_event_work() has a number of problems.
+
+- It does not aquire the locks to call the detect helper and update
+the connector status. These are struct drm_mode_config.connection_mutex
+and struct drm_mode_config.mutex.
+
+- It does not use drm_helper_probe_detect(), which helps with the
+details of locking and detection.
+
+- It uses the connector's status field to determine a change to
+the connector status. The epoch_counter field is the correct one. The
+field signals a change even if the connector status' value did not
+change.
+
+Replace the code with a call to drm_connector_helper_hpd_irq_event(),
+which fixes all these problems.
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Fixes: 81632df69772 ("drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event")
+Cc: Chris Zhong <zyw@rock-chips.com>
+Cc: Guenter Roeck <groeck@chromium.org>
+Cc: Sandy Huang <hjc@rock-chips.com>
+Cc: "Heiko Stübner" <heiko@sntech.de>
+Cc: Andy Yan <andy.yan@rock-chips.com>
+Cc: dri-devel@lists.freedesktop.org
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-rockchip@lists.infradead.org
+Cc: <stable@vger.kernel.org> # v4.11+
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20241105133848.480407-1-tzimmermann@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 +--------
+ 1 file changed, 1 insertion(+), 8 deletions(-)
+
+--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
++++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
+@@ -946,9 +946,6 @@ static void cdn_dp_pd_event_work(struct
+ {
+ struct cdn_dp_device *dp = container_of(work, struct cdn_dp_device,
+ event_work);
+- struct drm_connector *connector = &dp->connector;
+- enum drm_connector_status old_status;
+-
+ int ret;
+
+ mutex_lock(&dp->lock);
+@@ -1010,11 +1007,7 @@ static void cdn_dp_pd_event_work(struct
+
+ out:
+ mutex_unlock(&dp->lock);
+-
+- old_status = connector->status;
+- connector->status = connector->funcs->detect(connector, false);
+- if (old_status != connector->status)
+- drm_kms_helper_hotplug_event(dp->drm_dev);
++ drm_connector_helper_hpd_irq_event(&dp->connector);
+ }
+
+ static int cdn_dp_pd_event(struct notifier_block *nb,
--- /dev/null
+From ab251dacfbae28772c897f068a4184f478189ff2 Mon Sep 17 00:00:00 2001
+From: Nam Cao <namcao@linutronix.de>
+Date: Thu, 2 Jan 2025 09:22:56 +0100
+Subject: fs/proc: do_task_stat: Fix ESP not readable during coredump
+
+From: Nam Cao <namcao@linutronix.de>
+
+commit ab251dacfbae28772c897f068a4184f478189ff2 upstream.
+
+The field "eip" (instruction pointer) and "esp" (stack pointer) of a task
+can be read from /proc/PID/stat. These fields can be interesting for
+coredump.
+
+However, these fields were disabled by commit 0a1eb2d474ed ("fs/proc: Stop
+reporting eip and esp in /proc/PID/stat"), because it is generally unsafe
+to do so. But it is safe for a coredumping process, and therefore
+exceptions were made:
+
+ - for a coredumping thread by commit fd7d56270b52 ("fs/proc: Report
+ eip/esp in /prod/PID/stat for coredumping").
+
+ - for all other threads in a coredumping process by commit cb8f381f1613
+ ("fs/proc/array.c: allow reporting eip/esp for all coredumping
+ threads").
+
+The above two commits check the PF_DUMPCORE flag to determine a coredump thread
+and the PF_EXITING flag for the other threads.
+
+Unfortunately, commit 92307383082d ("coredump: Don't perform any cleanups
+before dumping core") moved coredump to happen earlier and before PF_EXITING is
+set. Thus, checking PF_EXITING is no longer the correct way to determine
+threads in a coredumping process.
+
+Instead of PF_EXITING, use PF_POSTCOREDUMP to determine the other threads.
+
+Checking of PF_EXITING was added for coredumping, so it probably can now be
+removed. But it doesn't hurt to keep.
+
+Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping core")
+Cc: stable@vger.kernel.org
+Cc: Eric W. Biederman <ebiederm@xmission.com>
+Acked-by: Oleg Nesterov <oleg@redhat.com>
+Acked-by: Kees Cook <kees@kernel.org>
+Signed-off-by: Nam Cao <namcao@linutronix.de>
+Link: https://lore.kernel.org/r/d89af63d478d6c64cc46a01420b46fd6eb147d6f.1735805772.git.namcao@linutronix.de
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/proc/array.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/proc/array.c
++++ b/fs/proc/array.c
+@@ -500,7 +500,7 @@ static int do_task_stat(struct seq_file
+ * a program is not able to use ptrace(2) in that case. It is
+ * safe because the task has stopped executing permanently.
+ */
+- if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE))) {
++ if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE|PF_POSTCOREDUMP))) {
+ if (try_get_task_stack(task)) {
+ eip = KSTK_EIP(task);
+ esp = KSTK_ESP(task);
--- /dev/null
+From aab98e2dbd648510f8f51b83fbf4721206ccae45 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@linaro.org>
+Date: Wed, 15 Jan 2025 09:28:35 +0900
+Subject: ksmbd: fix integer overflows on 32 bit systems
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+commit aab98e2dbd648510f8f51b83fbf4721206ccae45 upstream.
+
+On 32bit systems the addition operations in ipc_msg_alloc() can
+potentially overflow leading to memory corruption.
+Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.
+
+Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
+Cc: stable@vger.kernel.org
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/server/transport_ipc.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/smb/server/transport_ipc.c
++++ b/fs/smb/server/transport_ipc.c
+@@ -570,6 +570,9 @@ ksmbd_ipc_spnego_authen_request(const ch
+ struct ksmbd_spnego_authen_request *req;
+ struct ksmbd_spnego_authen_response *resp;
+
++ if (blob_len > KSMBD_IPC_MAX_PAYLOAD)
++ return NULL;
++
+ msg = ipc_msg_alloc(sizeof(struct ksmbd_spnego_authen_request) +
+ blob_len + 1);
+ if (!msg)
+@@ -749,6 +752,9 @@ struct ksmbd_rpc_command *ksmbd_rpc_writ
+ struct ksmbd_rpc_command *req;
+ struct ksmbd_rpc_command *resp;
+
++ if (payload_sz > KSMBD_IPC_MAX_PAYLOAD)
++ return NULL;
++
+ msg = ipc_msg_alloc(sizeof(struct ksmbd_rpc_command) + payload_sz + 1);
+ if (!msg)
+ return NULL;
+@@ -797,6 +803,9 @@ struct ksmbd_rpc_command *ksmbd_rpc_ioct
+ struct ksmbd_rpc_command *req;
+ struct ksmbd_rpc_command *resp;
+
++ if (payload_sz > KSMBD_IPC_MAX_PAYLOAD)
++ return NULL;
++
+ msg = ipc_msg_alloc(sizeof(struct ksmbd_rpc_command) + payload_sz + 1);
+ if (!msg)
+ return NULL;
--- /dev/null
+From b450dcce93bc2cf6d2bfaf5a0de88a94ebad8f89 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Tue, 4 Feb 2025 11:00:48 +0000
+Subject: KVM: arm64: timer: Always evaluate the need for a soft timer
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit b450dcce93bc2cf6d2bfaf5a0de88a94ebad8f89 upstream.
+
+When updating the interrupt state for an emulated timer, we return
+early and skip the setup of a soft timer that runs in parallel
+with the guest.
+
+While this is OK if we have set the interrupt pending, it is pretty
+wrong if the guest moved CVAL into the future. In that case,
+no timer is armed and the guest can wait for a very long time
+(it will take a full put/load cycle for the situation to resolve).
+
+This is specially visible with EDK2 running at EL2, but still
+using the EL1 virtual timer, which in that case is fully emulated.
+Any key-press takes ages to be captured, as there is no UART
+interrupt and EDK2 relies on polling from a timer...
+
+The fix is simply to drop the early return. If the timer interrupt
+is pending, we will still return early, and otherwise arm the soft
+timer.
+
+Fixes: 4d74ecfa6458b ("KVM: arm64: Don't arm a hrtimer for an already pending timer")
+Cc: stable@vger.kernel.org
+Tested-by: Dmytro Terletskyi <dmytro_terletskyi@epam.com>
+Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
+Link: https://lore.kernel.org/r/20250204110050.150560-2-maz@kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/arch_timer.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/arch/arm64/kvm/arch_timer.c
++++ b/arch/arm64/kvm/arch_timer.c
+@@ -467,10 +467,8 @@ static void timer_emulate(struct arch_ti
+
+ trace_kvm_timer_emulate(ctx, should_fire);
+
+- if (should_fire != ctx->irq.level) {
++ if (should_fire != ctx->irq.level)
+ kvm_timer_update_irq(ctx->vcpu, should_fire, ctx);
+- return;
+- }
+
+ /*
+ * If the timer can fire now, we don't need to have a soft timer
--- /dev/null
+From 1e7381f3617d14b3c11da80ff5f8a93ab14cfc46 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Wed, 9 Oct 2024 08:04:50 -0700
+Subject: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 1e7381f3617d14b3c11da80ff5f8a93ab14cfc46 upstream.
+
+Explicitly verify the target vCPU is fully online _prior_ to clamping the
+index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will
+generate '0', i.e. KVM will return vCPU0 instead of NULL.
+
+In practice, the bug is unlikely to cause problems, as it will only come
+into play if userspace or the guest is buggy or misbehaving, e.g. KVM may
+send interrupts to vCPU0 instead of dropping them on the floor.
+
+However, returning vCPU0 when it shouldn't exist per online_vcpus is
+problematic now that KVM uses an xarray for the vCPUs array, as KVM needs
+to insert into the xarray before publishing the vCPU to userspace (see
+commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),
+i.e. before vCPU creation is guaranteed to succeed.
+
+As a result, incorrectly providing access to vCPU0 will trigger a
+use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()
+bails out of vCPU creation due to an error and frees vCPU0. Commit
+afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but
+in doing so introduced an unsolvable teardown conundrum. Preventing
+accesses to vCPU0 before it's fully online will allow reverting commit
+afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.
+
+Fixes: 1d487e9bf8ba ("KVM: fix spectrev1 gadgets")
+Cc: stable@vger.kernel.org
+Cc: Will Deacon <will@kernel.org>
+Cc: Michal Luczaj <mhal@rbox.co>
+Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>
+Acked-by: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20241009150455.1057573-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/kvm_host.h | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/include/linux/kvm_host.h
++++ b/include/linux/kvm_host.h
+@@ -920,6 +920,15 @@ static inline struct kvm_io_bus *kvm_get
+ static inline struct kvm_vcpu *kvm_get_vcpu(struct kvm *kvm, int i)
+ {
+ int num_vcpus = atomic_read(&kvm->online_vcpus);
++
++ /*
++ * Explicitly verify the target vCPU is online, as the anti-speculation
++ * logic only limits the CPU's ability to speculate, e.g. given a "bad"
++ * index, clamping the index to 0 would return vCPU0, not NULL.
++ */
++ if (i >= num_vcpus)
++ return NULL;
++
+ i = array_index_nospec(i, num_vcpus);
+
+ /* Pairs with smp_wmb() in kvm_vm_ioctl_create_vcpu. */
--- /dev/null
+From 5f230f41fdd9e799f43a699348dc572bca7159aa Mon Sep 17 00:00:00 2001
+From: David Hildenbrand <david@redhat.com>
+Date: Tue, 7 Jan 2025 16:43:41 +0100
+Subject: KVM: s390: vsie: fix some corner-cases when grabbing vsie pages
+
+From: David Hildenbrand <david@redhat.com>
+
+commit 5f230f41fdd9e799f43a699348dc572bca7159aa upstream.
+
+We try to reuse the same vsie page when re-executing the vsie with a
+given SCB address. The result is that we use the same shadow SCB --
+residing in the vsie page -- and can avoid flushing the TLB when
+re-running the vsie on a CPU.
+
+So, when we allocate a fresh vsie page, or when we reuse a vsie page for
+a different SCB address -- reusing the shadow SCB in different context --
+we set ihcpu=0xffff to trigger the flush.
+
+However, after we looked up the SCB address in the radix tree, but before
+we grabbed the vsie page by raising the refcount to 2, someone could reuse
+the vsie page for a different SCB address, adjusting page->index and the
+radix tree. In that case, we would be reusing the vsie page with a
+wrong page->index.
+
+Another corner case is that we might set the SCB address for a vsie
+page, but fail the insertion into the radix tree. Whoever would reuse
+that page would remove the corresponding radix tree entry -- which might
+now be a valid entry pointing at another page, resulting in the wrong
+vsie page getting removed from the radix tree.
+
+Let's handle such races better, by validating that the SCB address of a
+vsie page didn't change after we grabbed it (not reuse for a different
+SCB; the alternative would be performing another tree lookup), and by
+setting the SCB address to invalid until the insertion in the tree
+succeeded (SCB addresses are aligned to 512, so ULONG_MAX is invalid).
+
+These scenarios are rare, the effects a bit unclear, and these issues were
+only found by code inspection. Let's CC stable to be safe.
+
+Fixes: a3508fbe9dc6 ("KVM: s390: vsie: initial support for nested virtualization")
+Cc: stable@vger.kernel.org
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Reviewed-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
+Tested-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
+Message-ID: <20250107154344.1003072-2-david@redhat.com>
+Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/kvm/vsie.c | 25 +++++++++++++++++++------
+ 1 file changed, 19 insertions(+), 6 deletions(-)
+
+--- a/arch/s390/kvm/vsie.c
++++ b/arch/s390/kvm/vsie.c
+@@ -1335,8 +1335,14 @@ static struct vsie_page *get_vsie_page(s
+ page = radix_tree_lookup(&kvm->arch.vsie.addr_to_page, addr >> 9);
+ rcu_read_unlock();
+ if (page) {
+- if (page_ref_inc_return(page) == 2)
+- return page_to_virt(page);
++ if (page_ref_inc_return(page) == 2) {
++ if (page->index == addr)
++ return page_to_virt(page);
++ /*
++ * We raced with someone reusing + putting this vsie
++ * page before we grabbed it.
++ */
++ }
+ page_ref_dec(page);
+ }
+
+@@ -1366,15 +1372,20 @@ static struct vsie_page *get_vsie_page(s
+ kvm->arch.vsie.next++;
+ kvm->arch.vsie.next %= nr_vcpus;
+ }
+- radix_tree_delete(&kvm->arch.vsie.addr_to_page, page->index >> 9);
++ if (page->index != ULONG_MAX)
++ radix_tree_delete(&kvm->arch.vsie.addr_to_page,
++ page->index >> 9);
+ }
+- page->index = addr;
+- /* double use of the same address */
++ /* Mark it as invalid until it resides in the tree. */
++ page->index = ULONG_MAX;
++
++ /* Double use of the same address or allocation failure. */
+ if (radix_tree_insert(&kvm->arch.vsie.addr_to_page, addr >> 9, page)) {
+ page_ref_dec(page);
+ mutex_unlock(&kvm->arch.vsie.mutex);
+ return NULL;
+ }
++ page->index = addr;
+ mutex_unlock(&kvm->arch.vsie.mutex);
+
+ vsie_page = page_to_virt(page);
+@@ -1467,7 +1478,9 @@ void kvm_s390_vsie_destroy(struct kvm *k
+ vsie_page = page_to_virt(page);
+ release_gmap_shadow(vsie_page);
+ /* free the radix tree entry */
+- radix_tree_delete(&kvm->arch.vsie.addr_to_page, page->index >> 9);
++ if (page->index != ULONG_MAX)
++ radix_tree_delete(&kvm->arch.vsie.addr_to_page,
++ page->index >> 9);
+ __free_page(page);
+ }
+ kvm->arch.vsie.page_count = 0;
--- /dev/null
+From 0d2e820a86793595e2a776855d04701109e46663 Mon Sep 17 00:00:00 2001
+From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+Date: Thu, 14 Nov 2024 11:13:59 +0100
+Subject: leds: lp8860: Write full EEPROM, not only half of it
+
+From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+
+commit 0d2e820a86793595e2a776855d04701109e46663 upstream.
+
+I struggle to explain dividing an ARRAY_SIZE() by the size of an element
+once again. As the latter equals to 2, only the half of EEPROM was ever
+written. Drop the unexplainable division and write full ARRAY_SIZE().
+
+Cc: stable@vger.kernel.org
+Fixes: 7a8685accb95 ("leds: lp8860: Introduce TI lp8860 4 channel LED driver")
+Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+Link: https://lore.kernel.org/r/20241114101402.2562878-1-alexander.sverdlin@siemens.com
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/leds/leds-lp8860.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/leds/leds-lp8860.c
++++ b/drivers/leds/leds-lp8860.c
+@@ -265,7 +265,7 @@ static int lp8860_init(struct lp8860_led
+ goto out;
+ }
+
+- reg_count = ARRAY_SIZE(lp8860_eeprom_disp_regs) / sizeof(lp8860_eeprom_disp_regs[0]);
++ reg_count = ARRAY_SIZE(lp8860_eeprom_disp_regs);
+ for (i = 0; i < reg_count; i++) {
+ ret = regmap_write(led->eeprom_regmap,
+ lp8860_eeprom_disp_regs[i].reg,
--- /dev/null
+From 53036937a101b5faeaf98e7438555fa854a1a844 Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Tue, 7 Jan 2025 10:58:56 +0100
+Subject: m68k: vga: Fix I/O defines
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit 53036937a101b5faeaf98e7438555fa854a1a844 upstream.
+
+Including m68k's <asm/raw_io.h> in vga.h on nommu platforms results
+in conflicting defines with io_no.h for various I/O macros from the
+__raw_read and __raw_write families. An example error is
+
+ In file included from arch/m68k/include/asm/vga.h:12,
+ from include/video/vga.h:22,
+ from include/linux/vgaarb.h:34,
+ from drivers/video/aperture.c:12:
+>> arch/m68k/include/asm/raw_io.h:39: warning: "__raw_readb" redefined
+ 39 | #define __raw_readb in_8
+ |
+ In file included from arch/m68k/include/asm/io.h:6,
+ from include/linux/io.h:13,
+ from include/linux/irq.h:20,
+ from include/asm-generic/hardirq.h:17,
+ from ./arch/m68k/include/generated/asm/hardirq.h:1,
+ from include/linux/hardirq.h:11,
+ from include/linux/interrupt.h:11,
+ from include/linux/trace_recursion.h:5,
+ from include/linux/ftrace.h:10,
+ from include/linux/kprobes.h:28,
+ from include/linux/kgdb.h:19,
+ from include/linux/fb.h:6,
+ from drivers/video/aperture.c:5:
+ arch/m68k/include/asm/io_no.h:16: note: this is the location of the previous definition
+ 16 | #define __raw_readb(addr) \
+ |
+
+Include <asm/io.h>, which avoids raw_io.h on nommu platforms.
+Also change the defined values of some of the read/write symbols in
+vga.h to __raw_read/__raw_write as the raw_in/raw_out symbols are not
+generally available.
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202501071629.DNEswlm8-lkp@intel.com/
+Fixes: 5c3f968712ce ("m68k/video: Create <asm/vga.h>")
+Cc: Geert Uytterhoeven <geert@linux-m68k.org>
+Cc: linux-fbdev@vger.kernel.org
+Cc: dri-devel@lists.freedesktop.org
+Cc: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # v3.5+
+Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Link: https://lore.kernel.org/20250107095912.130530-1-tzimmermann@suse.de
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/m68k/include/asm/vga.h | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/m68k/include/asm/vga.h
++++ b/arch/m68k/include/asm/vga.h
+@@ -9,7 +9,7 @@
+ */
+ #ifndef CONFIG_PCI
+
+-#include <asm/raw_io.h>
++#include <asm/io.h>
+ #include <asm/kmap.h>
+
+ /*
+@@ -29,9 +29,9 @@
+ #define inw_p(port) 0
+ #define outb_p(port, val) do { } while (0)
+ #define outw(port, val) do { } while (0)
+-#define readb raw_inb
+-#define writeb raw_outb
+-#define writew raw_outw
++#define readb __raw_readb
++#define writeb __raw_writeb
++#define writew __raw_writew
+
+ #endif /* CONFIG_PCI */
+ #endif /* _ASM_M68K_VGA_H */
--- /dev/null
+From f245b400a223a71d6d5f4c72a2cb9b573a7fc2b6 Mon Sep 17 00:00:00 2001
+From: Tom Chung <chiahsuan.chung@amd.com>
+Date: Tue, 4 Feb 2025 15:07:44 +0800
+Subject: Revert "drm/amd/display: Use HW lock mgr for PSR1"
+
+From: Tom Chung <chiahsuan.chung@amd.com>
+
+commit f245b400a223a71d6d5f4c72a2cb9b573a7fc2b6 upstream.
+
+This reverts commit
+a2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1")
+
+Because it may cause system hang while connect with two edp panel.
+
+Acked-by: Wayne Lin <wayne.lin@amd.com>
+Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/dce/dmub_hw_lock_mgr.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_hw_lock_mgr.c
++++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_hw_lock_mgr.c
+@@ -63,8 +63,7 @@ void dmub_hw_lock_mgr_inbox0_cmd(struct
+
+ bool should_use_dmub_lock(struct dc_link *link)
+ {
+- if (link->psr_settings.psr_version == DC_PSR_VERSION_SU_1 ||
+- link->psr_settings.psr_version == DC_PSR_VERSION_1)
++ if (link->psr_settings.psr_version == DC_PSR_VERSION_SU_1)
+ return true;
+ return false;
+ }
--- /dev/null
+From 26701574cee6777f867f89b4a5c667817e1ee0dd Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <hca@linux.ibm.com>
+Date: Tue, 7 Jan 2025 11:28:58 +0100
+Subject: s390/futex: Fix FUTEX_OP_ANDN implementation
+
+From: Heiko Carstens <hca@linux.ibm.com>
+
+commit 26701574cee6777f867f89b4a5c667817e1ee0dd upstream.
+
+The futex operation FUTEX_OP_ANDN is supposed to implement
+
+*(int *)UADDR2 &= ~OPARG;
+
+The s390 implementation just implements an AND instead of ANDN.
+Add the missing bitwise not operation to oparg to fix this.
+
+This is broken since nearly 19 years, so it looks like user space is
+not making use of this operation.
+
+Fixes: 3363fbdd6fb4 ("[PATCH] s390: futex atomic operations")
+Cc: stable@vger.kernel.org
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/include/asm/futex.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/s390/include/asm/futex.h
++++ b/arch/s390/include/asm/futex.h
+@@ -44,7 +44,7 @@ static inline int arch_futex_atomic_op_i
+ break;
+ case FUTEX_OP_ANDN:
+ __futex_atomic_op("lr %2,%1\nnr %2,%5\n",
+- ret, oldval, newval, uaddr, oparg);
++ ret, oldval, newval, uaddr, ~oparg);
+ break;
+ case FUTEX_OP_XOR:
+ __futex_atomic_op("lr %2,%1\nxr %2,%5\n",
tun-revert-fix-group-permission-check.patch
net-sched-fix-truncation-of-offloaded-action-statist.patch
rxrpc-fix-call-state-set-to-not-include-the-server_s.patch
+cpufreq-s3c64xx-fix-compilation-warning.patch
+leds-lp8860-write-full-eeprom-not-only-half-of-it.patch
+alsa-hda-realtek-enable-mute-led-on-hp-laptop-14s-fq1xxx.patch
+drm-modeset-handle-tiled-displays-in-pan_display_atomic.patch
+smb-client-fix-order-of-arguments-of-tracepoints.patch
+smb-client-change-lease-epoch-type-from-unsigned-int-to-__u16.patch
+s390-futex-fix-futex_op_andn-implementation.patch
+m68k-vga-fix-i-o-defines.patch
+fs-proc-do_task_stat-fix-esp-not-readable-during-coredump.patch
+binfmt_flat-fix-integer-overflow-bug-on-32-bit-systems.patch
+kvm-arm64-timer-always-evaluate-the-need-for-a-soft-timer.patch
+drm-rockchip-cdn-dp-use-drm_connector_helper_hpd_irq_event.patch
+arm64-dts-rockchip-increase-gmac-rx_delay-on-rk3399-puma.patch
+kvm-explicitly-verify-target-vcpu-is-online-in-kvm_get_vcpu.patch
+kvm-s390-vsie-fix-some-corner-cases-when-grabbing-vsie-pages.patch
+ksmbd-fix-integer-overflows-on-32-bit-systems.patch
+drm-amd-pm-mark-mm-activity-as-unsupported.patch
+drm-amdkfd-only-flush-the-validate-mes-contex.patch
+revert-drm-amd-display-use-hw-lock-mgr-for-psr1.patch
+drm-i915-guc-debug-print-lrc-state-entries-only-if-the-context-is-pinned.patch
+drm-i915-fix-page-cleanup-on-dma-remap-failure.patch
+drm-komeda-add-check-for-komeda_get_layer_fourcc_list.patch
+drm-i915-drop-64bpp-yuv-formats-from-icl-sdr-planes.patch
+bluetooth-l2cap-handle-null-sock-pointer-in-l2cap_sock_alloc.patch
+bluetooth-l2cap-accept-zero-as-a-special-value-for-mtu-auto-selection.patch
--- /dev/null
+From 57e4a9bd61c308f607bc3e55e8fa02257b06b552 Mon Sep 17 00:00:00 2001
+From: Meetakshi Setiya <msetiya@microsoft.com>
+Date: Thu, 6 Feb 2025 01:50:41 -0500
+Subject: smb: client: change lease epoch type from unsigned int to __u16
+
+From: Meetakshi Setiya <msetiya@microsoft.com>
+
+commit 57e4a9bd61c308f607bc3e55e8fa02257b06b552 upstream.
+
+MS-SMB2 section 2.2.13.2.10 specifies that 'epoch' should be a 16-bit
+unsigned integer used to track lease state changes. Change the data
+type of all instances of 'epoch' from unsigned int to __u16. This
+simplifies the epoch change comparisons and makes the code more
+compliant with the protocol spec.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Meetakshi Setiya <msetiya@microsoft.com>
+Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/cifsglob.h | 14 +++++++-------
+ fs/smb/client/smb1ops.c | 2 +-
+ fs/smb/client/smb2ops.c | 18 +++++++++---------
+ fs/smb/client/smb2pdu.c | 2 +-
+ fs/smb/client/smb2proto.h | 2 +-
+ 5 files changed, 19 insertions(+), 19 deletions(-)
+
+--- a/fs/smb/client/cifsglob.h
++++ b/fs/smb/client/cifsglob.h
+@@ -323,7 +323,7 @@ struct smb_version_operations {
+ int (*handle_cancelled_mid)(struct mid_q_entry *, struct TCP_Server_Info *);
+ void (*downgrade_oplock)(struct TCP_Server_Info *server,
+ struct cifsInodeInfo *cinode, __u32 oplock,
+- unsigned int epoch, bool *purge_cache);
++ __u16 epoch, bool *purge_cache);
+ /* process transaction2 response */
+ bool (*check_trans2)(struct mid_q_entry *, struct TCP_Server_Info *,
+ char *, int);
+@@ -519,12 +519,12 @@ struct smb_version_operations {
+ /* if we can do cache read operations */
+ bool (*is_read_op)(__u32);
+ /* set oplock level for the inode */
+- void (*set_oplock_level)(struct cifsInodeInfo *, __u32, unsigned int,
+- bool *);
++ void (*set_oplock_level)(struct cifsInodeInfo *cinode, __u32 oplock, __u16 epoch,
++ bool *purge_cache);
+ /* create lease context buffer for CREATE request */
+ char * (*create_lease_buf)(u8 *lease_key, u8 oplock);
+ /* parse lease context buffer and return oplock/epoch info */
+- __u8 (*parse_lease_buf)(void *buf, unsigned int *epoch, char *lkey);
++ __u8 (*parse_lease_buf)(void *buf, __u16 *epoch, char *lkey);
+ ssize_t (*copychunk_range)(const unsigned int,
+ struct cifsFileInfo *src_file,
+ struct cifsFileInfo *target_file,
+@@ -1412,7 +1412,7 @@ struct cifs_fid {
+ __u8 create_guid[16];
+ __u32 access;
+ struct cifs_pending_open *pending_open;
+- unsigned int epoch;
++ __u16 epoch;
+ #ifdef CONFIG_CIFS_DEBUG2
+ __u64 mid;
+ #endif /* CIFS_DEBUG2 */
+@@ -1445,7 +1445,7 @@ struct cifsFileInfo {
+ bool oplock_break_cancelled:1;
+ bool status_file_deleted:1; /* file has been deleted */
+ bool offload:1; /* offload final part of _put to a wq */
+- unsigned int oplock_epoch; /* epoch from the lease break */
++ __u16 oplock_epoch; /* epoch from the lease break */
+ __u32 oplock_level; /* oplock/lease level from the lease break */
+ int count;
+ spinlock_t file_info_lock; /* protects four flag/count fields above */
+@@ -1584,7 +1584,7 @@ struct cifsInodeInfo {
+ spinlock_t open_file_lock; /* protects openFileList */
+ __u32 cifsAttrs; /* e.g. DOS archive bit, sparse, compressed, system */
+ unsigned int oplock; /* oplock/lease level we have */
+- unsigned int epoch; /* used to track lease state changes */
++ __u16 epoch; /* used to track lease state changes */
+ #define CIFS_INODE_PENDING_OPLOCK_BREAK (0) /* oplock break in progress */
+ #define CIFS_INODE_PENDING_WRITERS (1) /* Writes in progress */
+ #define CIFS_INODE_FLAG_UNUSED (2) /* Unused flag */
+--- a/fs/smb/client/smb1ops.c
++++ b/fs/smb/client/smb1ops.c
+@@ -377,7 +377,7 @@ coalesce_t2(char *second_buf, struct smb
+ static void
+ cifs_downgrade_oplock(struct TCP_Server_Info *server,
+ struct cifsInodeInfo *cinode, __u32 oplock,
+- unsigned int epoch, bool *purge_cache)
++ __u16 epoch, bool *purge_cache)
+ {
+ cifs_set_oplock_level(cinode, oplock);
+ }
+--- a/fs/smb/client/smb2ops.c
++++ b/fs/smb/client/smb2ops.c
+@@ -3867,22 +3867,22 @@ static long smb3_fallocate(struct file *
+ static void
+ smb2_downgrade_oplock(struct TCP_Server_Info *server,
+ struct cifsInodeInfo *cinode, __u32 oplock,
+- unsigned int epoch, bool *purge_cache)
++ __u16 epoch, bool *purge_cache)
+ {
+ server->ops->set_oplock_level(cinode, oplock, 0, NULL);
+ }
+
+ static void
+ smb21_set_oplock_level(struct cifsInodeInfo *cinode, __u32 oplock,
+- unsigned int epoch, bool *purge_cache);
++ __u16 epoch, bool *purge_cache);
+
+ static void
+ smb3_downgrade_oplock(struct TCP_Server_Info *server,
+ struct cifsInodeInfo *cinode, __u32 oplock,
+- unsigned int epoch, bool *purge_cache)
++ __u16 epoch, bool *purge_cache)
+ {
+ unsigned int old_state = cinode->oplock;
+- unsigned int old_epoch = cinode->epoch;
++ __u16 old_epoch = cinode->epoch;
+ unsigned int new_state;
+
+ if (epoch > old_epoch) {
+@@ -3902,7 +3902,7 @@ smb3_downgrade_oplock(struct TCP_Server_
+
+ static void
+ smb2_set_oplock_level(struct cifsInodeInfo *cinode, __u32 oplock,
+- unsigned int epoch, bool *purge_cache)
++ __u16 epoch, bool *purge_cache)
+ {
+ oplock &= 0xFF;
+ cinode->lease_granted = false;
+@@ -3926,7 +3926,7 @@ smb2_set_oplock_level(struct cifsInodeIn
+
+ static void
+ smb21_set_oplock_level(struct cifsInodeInfo *cinode, __u32 oplock,
+- unsigned int epoch, bool *purge_cache)
++ __u16 epoch, bool *purge_cache)
+ {
+ char message[5] = {0};
+ unsigned int new_oplock = 0;
+@@ -3963,7 +3963,7 @@ smb21_set_oplock_level(struct cifsInodeI
+
+ static void
+ smb3_set_oplock_level(struct cifsInodeInfo *cinode, __u32 oplock,
+- unsigned int epoch, bool *purge_cache)
++ __u16 epoch, bool *purge_cache)
+ {
+ unsigned int old_oplock = cinode->oplock;
+
+@@ -4077,7 +4077,7 @@ smb3_create_lease_buf(u8 *lease_key, u8
+ }
+
+ static __u8
+-smb2_parse_lease_buf(void *buf, unsigned int *epoch, char *lease_key)
++smb2_parse_lease_buf(void *buf, __u16 *epoch, char *lease_key)
+ {
+ struct create_lease *lc = (struct create_lease *)buf;
+
+@@ -4088,7 +4088,7 @@ smb2_parse_lease_buf(void *buf, unsigned
+ }
+
+ static __u8
+-smb3_parse_lease_buf(void *buf, unsigned int *epoch, char *lease_key)
++smb3_parse_lease_buf(void *buf, __u16 *epoch, char *lease_key)
+ {
+ struct create_lease_v2 *lc = (struct create_lease_v2 *)buf;
+
+--- a/fs/smb/client/smb2pdu.c
++++ b/fs/smb/client/smb2pdu.c
+@@ -2322,7 +2322,7 @@ parse_posix_ctxt(struct create_context *
+
+ int smb2_parse_contexts(struct TCP_Server_Info *server,
+ struct kvec *rsp_iov,
+- unsigned int *epoch,
++ __u16 *epoch,
+ char *lease_key, __u8 *oplock,
+ struct smb2_file_all_info *buf,
+ struct create_posix_rsp *posix)
+--- a/fs/smb/client/smb2proto.h
++++ b/fs/smb/client/smb2proto.h
+@@ -283,7 +283,7 @@ extern enum securityEnum smb2_select_sec
+ enum securityEnum);
+ int smb2_parse_contexts(struct TCP_Server_Info *server,
+ struct kvec *rsp_iov,
+- unsigned int *epoch,
++ __u16 *epoch,
+ char *lease_key, __u8 *oplock,
+ struct smb2_file_all_info *buf,
+ struct create_posix_rsp *posix);
--- /dev/null
+From 11f8b80ab9f99291dc88d09855b9f8f43b772335 Mon Sep 17 00:00:00 2001
+From: Ruben Devos <devosruben6@gmail.com>
+Date: Sat, 18 Jan 2025 21:03:30 +0100
+Subject: smb: client: fix order of arguments of tracepoints
+
+From: Ruben Devos <devosruben6@gmail.com>
+
+commit 11f8b80ab9f99291dc88d09855b9f8f43b772335 upstream.
+
+The tracepoints based on smb3_inf_compound_*_class have tcon id and
+session id swapped around. This results in incorrect output in
+`trace-cmd report`.
+
+Fix the order of arguments to resolve this issue. The trace-cmd output
+below shows the before and after of the smb3_delete_enter and
+smb3_delete_done events as an example. The smb3_cmd_* events show the
+correct session and tcon id for reference.
+
+Also fix tracepoint set -> get in the SMB2_OP_GET_REPARSE case.
+
+BEFORE:
+rm-2211 [001] ..... 1839.550888: smb3_delete_enter: xid=281 sid=0x5 tid=0x3d path=\hello2.txt
+rm-2211 [001] ..... 1839.550894: smb3_cmd_enter: sid=0x1ac000000003d tid=0x5 cmd=5 mid=61
+rm-2211 [001] ..... 1839.550896: smb3_cmd_enter: sid=0x1ac000000003d tid=0x5 cmd=6 mid=62
+rm-2211 [001] ..... 1839.552091: smb3_cmd_done: sid=0x1ac000000003d tid=0x5 cmd=5 mid=61
+rm-2211 [001] ..... 1839.552093: smb3_cmd_done: sid=0x1ac000000003d tid=0x5 cmd=6 mid=62
+rm-2211 [001] ..... 1839.552103: smb3_delete_done: xid=281 sid=0x5 tid=0x3d
+
+AFTER:
+rm-2501 [001] ..... 3237.656110: smb3_delete_enter: xid=88 sid=0x1ac0000000041 tid=0x5 path=\hello2.txt
+rm-2501 [001] ..... 3237.656122: smb3_cmd_enter: sid=0x1ac0000000041 tid=0x5 cmd=5 mid=84
+rm-2501 [001] ..... 3237.656123: smb3_cmd_enter: sid=0x1ac0000000041 tid=0x5 cmd=6 mid=85
+rm-2501 [001] ..... 3237.657909: smb3_cmd_done: sid=0x1ac0000000041 tid=0x5 cmd=5 mid=84
+rm-2501 [001] ..... 3237.657909: smb3_cmd_done: sid=0x1ac0000000041 tid=0x5 cmd=6 mid=85
+rm-2501 [001] ..... 3237.657922: smb3_delete_done: xid=88 sid=0x1ac0000000041 tid=0x5
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ruben Devos <devosruben6@gmail.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/dir.c | 6 +-
+ fs/smb/client/smb2inode.c | 108 +++++++++++++++++++++++-----------------------
+ 2 files changed, 57 insertions(+), 57 deletions(-)
+
+--- a/fs/smb/client/dir.c
++++ b/fs/smb/client/dir.c
+@@ -627,7 +627,7 @@ int cifs_mknod(struct mnt_idmap *idmap,
+ goto mknod_out;
+ }
+
+- trace_smb3_mknod_enter(xid, tcon->ses->Suid, tcon->tid, full_path);
++ trace_smb3_mknod_enter(xid, tcon->tid, tcon->ses->Suid, full_path);
+
+ rc = tcon->ses->server->ops->make_node(xid, inode, direntry, tcon,
+ full_path, mode,
+@@ -635,9 +635,9 @@ int cifs_mknod(struct mnt_idmap *idmap,
+
+ mknod_out:
+ if (rc)
+- trace_smb3_mknod_err(xid, tcon->ses->Suid, tcon->tid, rc);
++ trace_smb3_mknod_err(xid, tcon->tid, tcon->ses->Suid, rc);
+ else
+- trace_smb3_mknod_done(xid, tcon->ses->Suid, tcon->tid);
++ trace_smb3_mknod_done(xid, tcon->tid, tcon->ses->Suid);
+
+ free_dentry_path(page);
+ free_xid(xid);
+--- a/fs/smb/client/smb2inode.c
++++ b/fs/smb/client/smb2inode.c
+@@ -298,8 +298,8 @@ replay_again:
+ goto finished;
+ }
+ num_rqst++;
+- trace_smb3_query_info_compound_enter(xid, ses->Suid,
+- tcon->tid, full_path);
++ trace_smb3_query_info_compound_enter(xid, tcon->tid,
++ ses->Suid, full_path);
+ break;
+ case SMB2_OP_POSIX_QUERY_INFO:
+ rqst[num_rqst].rq_iov = &vars->qi_iov;
+@@ -334,18 +334,18 @@ replay_again:
+ goto finished;
+ }
+ num_rqst++;
+- trace_smb3_posix_query_info_compound_enter(xid, ses->Suid,
+- tcon->tid, full_path);
++ trace_smb3_posix_query_info_compound_enter(xid, tcon->tid,
++ ses->Suid, full_path);
+ break;
+ case SMB2_OP_DELETE:
+- trace_smb3_delete_enter(xid, ses->Suid, tcon->tid, full_path);
++ trace_smb3_delete_enter(xid, tcon->tid, ses->Suid, full_path);
+ break;
+ case SMB2_OP_MKDIR:
+ /*
+ * Directories are created through parameters in the
+ * SMB2_open() call.
+ */
+- trace_smb3_mkdir_enter(xid, ses->Suid, tcon->tid, full_path);
++ trace_smb3_mkdir_enter(xid, tcon->tid, ses->Suid, full_path);
+ break;
+ case SMB2_OP_RMDIR:
+ rqst[num_rqst].rq_iov = &vars->si_iov[0];
+@@ -363,7 +363,7 @@ replay_again:
+ goto finished;
+ smb2_set_next_command(tcon, &rqst[num_rqst]);
+ smb2_set_related(&rqst[num_rqst++]);
+- trace_smb3_rmdir_enter(xid, ses->Suid, tcon->tid, full_path);
++ trace_smb3_rmdir_enter(xid, tcon->tid, ses->Suid, full_path);
+ break;
+ case SMB2_OP_SET_EOF:
+ rqst[num_rqst].rq_iov = &vars->si_iov[0];
+@@ -398,7 +398,7 @@ replay_again:
+ goto finished;
+ }
+ num_rqst++;
+- trace_smb3_set_eof_enter(xid, ses->Suid, tcon->tid, full_path);
++ trace_smb3_set_eof_enter(xid, tcon->tid, ses->Suid, full_path);
+ break;
+ case SMB2_OP_SET_INFO:
+ rqst[num_rqst].rq_iov = &vars->si_iov[0];
+@@ -429,8 +429,8 @@ replay_again:
+ goto finished;
+ }
+ num_rqst++;
+- trace_smb3_set_info_compound_enter(xid, ses->Suid,
+- tcon->tid, full_path);
++ trace_smb3_set_info_compound_enter(xid, tcon->tid,
++ ses->Suid, full_path);
+ break;
+ case SMB2_OP_RENAME:
+ rqst[num_rqst].rq_iov = &vars->si_iov[0];
+@@ -469,7 +469,7 @@ replay_again:
+ goto finished;
+ }
+ num_rqst++;
+- trace_smb3_rename_enter(xid, ses->Suid, tcon->tid, full_path);
++ trace_smb3_rename_enter(xid, tcon->tid, ses->Suid, full_path);
+ break;
+ case SMB2_OP_HARDLINK:
+ rqst[num_rqst].rq_iov = &vars->si_iov[0];
+@@ -496,7 +496,7 @@ replay_again:
+ goto finished;
+ smb2_set_next_command(tcon, &rqst[num_rqst]);
+ smb2_set_related(&rqst[num_rqst++]);
+- trace_smb3_hardlink_enter(xid, ses->Suid, tcon->tid, full_path);
++ trace_smb3_hardlink_enter(xid, tcon->tid, ses->Suid, full_path);
+ break;
+ case SMB2_OP_SET_REPARSE:
+ rqst[num_rqst].rq_iov = vars->io_iov;
+@@ -523,8 +523,8 @@ replay_again:
+ goto finished;
+ }
+ num_rqst++;
+- trace_smb3_set_reparse_compound_enter(xid, ses->Suid,
+- tcon->tid, full_path);
++ trace_smb3_set_reparse_compound_enter(xid, tcon->tid,
++ ses->Suid, full_path);
+ break;
+ case SMB2_OP_GET_REPARSE:
+ rqst[num_rqst].rq_iov = vars->io_iov;
+@@ -549,8 +549,8 @@ replay_again:
+ goto finished;
+ }
+ num_rqst++;
+- trace_smb3_get_reparse_compound_enter(xid, ses->Suid,
+- tcon->tid, full_path);
++ trace_smb3_get_reparse_compound_enter(xid, tcon->tid,
++ ses->Suid, full_path);
+ break;
+ case SMB2_OP_QUERY_WSL_EA:
+ rqst[num_rqst].rq_iov = &vars->ea_iov;
+@@ -663,11 +663,11 @@ finished:
+ }
+ SMB2_query_info_free(&rqst[num_rqst++]);
+ if (rc)
+- trace_smb3_query_info_compound_err(xid, ses->Suid,
+- tcon->tid, rc);
++ trace_smb3_query_info_compound_err(xid, tcon->tid,
++ ses->Suid, rc);
+ else
+- trace_smb3_query_info_compound_done(xid, ses->Suid,
+- tcon->tid);
++ trace_smb3_query_info_compound_done(xid, tcon->tid,
++ ses->Suid);
+ break;
+ case SMB2_OP_POSIX_QUERY_INFO:
+ idata = in_iov[i].iov_base;
+@@ -690,15 +690,15 @@ finished:
+
+ SMB2_query_info_free(&rqst[num_rqst++]);
+ if (rc)
+- trace_smb3_posix_query_info_compound_err(xid, ses->Suid,
+- tcon->tid, rc);
++ trace_smb3_posix_query_info_compound_err(xid, tcon->tid,
++ ses->Suid, rc);
+ else
+- trace_smb3_posix_query_info_compound_done(xid, ses->Suid,
+- tcon->tid);
++ trace_smb3_posix_query_info_compound_done(xid, tcon->tid,
++ ses->Suid);
+ break;
+ case SMB2_OP_DELETE:
+ if (rc)
+- trace_smb3_delete_err(xid, ses->Suid, tcon->tid, rc);
++ trace_smb3_delete_err(xid, tcon->tid, ses->Suid, rc);
+ else {
+ /*
+ * If dentry (hence, inode) is NULL, lease break is going to
+@@ -706,59 +706,59 @@ finished:
+ */
+ if (inode)
+ cifs_mark_open_handles_for_deleted_file(inode, full_path);
+- trace_smb3_delete_done(xid, ses->Suid, tcon->tid);
++ trace_smb3_delete_done(xid, tcon->tid, ses->Suid);
+ }
+ break;
+ case SMB2_OP_MKDIR:
+ if (rc)
+- trace_smb3_mkdir_err(xid, ses->Suid, tcon->tid, rc);
++ trace_smb3_mkdir_err(xid, tcon->tid, ses->Suid, rc);
+ else
+- trace_smb3_mkdir_done(xid, ses->Suid, tcon->tid);
++ trace_smb3_mkdir_done(xid, tcon->tid, ses->Suid);
+ break;
+ case SMB2_OP_HARDLINK:
+ if (rc)
+- trace_smb3_hardlink_err(xid, ses->Suid, tcon->tid, rc);
++ trace_smb3_hardlink_err(xid, tcon->tid, ses->Suid, rc);
+ else
+- trace_smb3_hardlink_done(xid, ses->Suid, tcon->tid);
++ trace_smb3_hardlink_done(xid, tcon->tid, ses->Suid);
+ SMB2_set_info_free(&rqst[num_rqst++]);
+ break;
+ case SMB2_OP_RENAME:
+ if (rc)
+- trace_smb3_rename_err(xid, ses->Suid, tcon->tid, rc);
++ trace_smb3_rename_err(xid, tcon->tid, ses->Suid, rc);
+ else
+- trace_smb3_rename_done(xid, ses->Suid, tcon->tid);
++ trace_smb3_rename_done(xid, tcon->tid, ses->Suid);
+ SMB2_set_info_free(&rqst[num_rqst++]);
+ break;
+ case SMB2_OP_RMDIR:
+ if (rc)
+- trace_smb3_rmdir_err(xid, ses->Suid, tcon->tid, rc);
++ trace_smb3_rmdir_err(xid, tcon->tid, ses->Suid, rc);
+ else
+- trace_smb3_rmdir_done(xid, ses->Suid, tcon->tid);
++ trace_smb3_rmdir_done(xid, tcon->tid, ses->Suid);
+ SMB2_set_info_free(&rqst[num_rqst++]);
+ break;
+ case SMB2_OP_SET_EOF:
+ if (rc)
+- trace_smb3_set_eof_err(xid, ses->Suid, tcon->tid, rc);
++ trace_smb3_set_eof_err(xid, tcon->tid, ses->Suid, rc);
+ else
+- trace_smb3_set_eof_done(xid, ses->Suid, tcon->tid);
++ trace_smb3_set_eof_done(xid, tcon->tid, ses->Suid);
+ SMB2_set_info_free(&rqst[num_rqst++]);
+ break;
+ case SMB2_OP_SET_INFO:
+ if (rc)
+- trace_smb3_set_info_compound_err(xid, ses->Suid,
+- tcon->tid, rc);
++ trace_smb3_set_info_compound_err(xid, tcon->tid,
++ ses->Suid, rc);
+ else
+- trace_smb3_set_info_compound_done(xid, ses->Suid,
+- tcon->tid);
++ trace_smb3_set_info_compound_done(xid, tcon->tid,
++ ses->Suid);
+ SMB2_set_info_free(&rqst[num_rqst++]);
+ break;
+ case SMB2_OP_SET_REPARSE:
+ if (rc) {
+- trace_smb3_set_reparse_compound_err(xid, ses->Suid,
+- tcon->tid, rc);
++ trace_smb3_set_reparse_compound_err(xid, tcon->tid,
++ ses->Suid, rc);
+ } else {
+- trace_smb3_set_reparse_compound_done(xid, ses->Suid,
+- tcon->tid);
++ trace_smb3_set_reparse_compound_done(xid, tcon->tid,
++ ses->Suid);
+ }
+ SMB2_ioctl_free(&rqst[num_rqst++]);
+ break;
+@@ -771,18 +771,18 @@ finished:
+ rbuf = reparse_buf_ptr(iov);
+ if (IS_ERR(rbuf)) {
+ rc = PTR_ERR(rbuf);
+- trace_smb3_set_reparse_compound_err(xid, ses->Suid,
+- tcon->tid, rc);
++ trace_smb3_get_reparse_compound_err(xid, tcon->tid,
++ ses->Suid, rc);
+ } else {
+ idata->reparse.tag = le32_to_cpu(rbuf->ReparseTag);
+- trace_smb3_set_reparse_compound_done(xid, ses->Suid,
+- tcon->tid);
++ trace_smb3_get_reparse_compound_done(xid, tcon->tid,
++ ses->Suid);
+ }
+ memset(iov, 0, sizeof(*iov));
+ resp_buftype[i + 1] = CIFS_NO_BUFFER;
+ } else {
+- trace_smb3_set_reparse_compound_err(xid, ses->Suid,
+- tcon->tid, rc);
++ trace_smb3_get_reparse_compound_err(xid, tcon->tid,
++ ses->Suid, rc);
+ }
+ SMB2_ioctl_free(&rqst[num_rqst++]);
+ break;
+@@ -799,11 +799,11 @@ finished:
+ }
+ }
+ if (!rc) {
+- trace_smb3_query_wsl_ea_compound_done(xid, ses->Suid,
+- tcon->tid);
++ trace_smb3_query_wsl_ea_compound_done(xid, tcon->tid,
++ ses->Suid);
+ } else {
+- trace_smb3_query_wsl_ea_compound_err(xid, ses->Suid,
+- tcon->tid, rc);
++ trace_smb3_query_wsl_ea_compound_err(xid, tcon->tid,
++ ses->Suid, rc);
+ }
+ SMB2_query_info_free(&rqst[num_rqst++]);
+ break;
projects / thirdparty / kernel / stable-queue.git / commitdiff
