--- /dev/null
+From 96e0b355883006554a0bee3697da475971d6bba8 Mon Sep 17 00:00:00 2001
+From: Ross Stutterheim <ross.stutterheim@garmin.com>
+Date: Wed, 16 Apr 2025 14:50:06 +0100
+Subject: ARM: 9447/1: arm/memremap: fix arch_memremap_can_ram_remap()
+
+From: Ross Stutterheim <ross.stutterheim@garmin.com>
+
+commit 96e0b355883006554a0bee3697da475971d6bba8 upstream.
+
+arm/memremap: fix arch_memremap_can_ram_remap()
+
+commit 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure
+presence of linear map") added the definition of
+arch_memremap_can_ram_remap() for arm[64] specific filtering of what pages
+can be used from the linear mapping. memblock_is_map_memory() was called
+with the pfn of the address given to arch_memremap_can_ram_remap();
+however, memblock_is_map_memory() expects to be given an address for arm,
+not a pfn.
+
+This results in calls to memremap() returning a newly mapped area when
+it should return an address in the existing linear mapping.
+
+Fix this by removing the address to pfn translation and pass the
+address directly.
+
+Fixes: 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map")
+Signed-off-by: Ross Stutterheim <ross.stutterheim@garmin.com>
+Cc: Mike Rapoport <rppt@kernel.org>
+Cc: stable@vger.kernel.org
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/mm/ioremap.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/arch/arm/mm/ioremap.c
++++ b/arch/arm/mm/ioremap.c
+@@ -515,7 +515,5 @@ void __init early_ioremap_init(void)
+ bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags)
+ {
+- unsigned long pfn = PHYS_PFN(offset);
+-
+- return memblock_is_map_memory(pfn);
++ return memblock_is_map_memory(offset);
+ }
--- /dev/null
+From 7397daf1029d5bfd3415ec8622f5179603d5702d Mon Sep 17 00:00:00 2001
+From: Andreas Kemnade <andreas@kemnade.info>
+Date: Mon, 31 Mar 2025 16:44:39 +0200
+Subject: ARM: omap: pmic-cpcap: do not mess around without CPCAP or OMAP4
+
+From: Andreas Kemnade <andreas@kemnade.info>
+
+commit 7397daf1029d5bfd3415ec8622f5179603d5702d upstream.
+
+The late init call just writes to omap4 registers as soon as
+CONFIG_MFD_CPCAP is enabled without checking whether the
+cpcap driver is actually there or the SoC is indeed an
+OMAP4.
+Rather do these things only with the right device combination.
+
+Fixes booting the BT200 with said configuration enabled and non-factory
+X-Loader and probably also some surprising behavior on other devices.
+
+Fixes: c145649bf262 ("ARM: OMAP2+: Configure voltage controller for cpcap to low-speed")
+CC: stable@vger.kernel.org
+Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
+Reivewed-by: Tony Lindgren <tony@atomide.com>
+Link: https://lore.kernel.org/r/20250331144439.769697-1-andreas@kemnade.info
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/mach-omap2/pmic-cpcap.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/mach-omap2/pmic-cpcap.c
++++ b/arch/arm/mach-omap2/pmic-cpcap.c
+@@ -264,7 +264,11 @@ int __init omap4_cpcap_init(void)
+
+ static int __init cpcap_late_init(void)
+ {
+- omap4_vc_set_pmic_signaling(PWRDM_POWER_RET);
++ if (!of_find_compatible_node(NULL, NULL, "motorola,cpcap"))
++ return 0;
++
++ if (soc_is_omap443x() || soc_is_omap446x() || soc_is_omap447x())
++ omap4_vc_set_pmic_signaling(PWRDM_POWER_RET);
+
+ return 0;
+ }
--- /dev/null
+From d29fc02caad7f94b62d56ee1b01c954f9c961ba7 Mon Sep 17 00:00:00 2001
+From: Tasos Sahanidis <tasos@tasossah.com>
+Date: Mon, 19 May 2025 11:49:45 +0300
+Subject: ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330
+
+From: Tasos Sahanidis <tasos@tasossah.com>
+
+commit d29fc02caad7f94b62d56ee1b01c954f9c961ba7 upstream.
+
+The controller has a hardware bug that can hard hang the system when
+doing ATAPI DMAs without any trace of what happened. Depending on the
+device attached, it can also prevent the system from booting.
+
+In this case, the system hangs when reading the ATIP from optical media
+with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an
+Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,
+running at UDMA/33.
+
+The issue can be reproduced by running the same command with a cygwin
+build of cdrecord on WinXP, although it requires more attempts to cause
+it. The hang in that case is also resolved by forcing PIO. It doesn't
+appear that VIA has produced any drivers for that OS, thus no known
+workaround exists.
+
+HDDs attached to the controller do not suffer from any DMA issues.
+
+Cc: stable@vger.kernel.org
+Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/916677
+Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
+Link: https://lore.kernel.org/r/20250519085508.1398701-1-tasos@tasossah.com
+Signed-off-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/pata_via.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/pata_via.c
++++ b/drivers/ata/pata_via.c
+@@ -368,7 +368,8 @@ static unsigned int via_mode_filter(stru
+ }
+
+ if (dev->class == ATA_DEV_ATAPI &&
+- dmi_check_system(no_atapi_dma_dmi_table)) {
++ (dmi_check_system(no_atapi_dma_dmi_table) ||
++ config->id == PCI_DEVICE_ID_VIA_6415)) {
+ ata_dev_warn(dev, "controller locks up on ATAPI DMA, forcing PIO\n");
+ mask &= ATA_MASK_PIO;
+ }
--- /dev/null
+From dd7d8e012b23de158ca0188239c7a1f2a83b4484 Mon Sep 17 00:00:00 2001
+From: Ioana Ciornei <ioana.ciornei@nxp.com>
+Date: Tue, 8 Apr 2025 13:58:10 +0300
+Subject: bus: fsl-mc: do not add a device-link for the UAPI used DPMCP device
+
+From: Ioana Ciornei <ioana.ciornei@nxp.com>
+
+commit dd7d8e012b23de158ca0188239c7a1f2a83b4484 upstream.
+
+The fsl-mc bus associated to the root DPRC in a DPAA2 system exports a
+device file for userspace access to the MC firmware. In case the DPRC's
+local MC portal (DPMCP) is currently in use, a new DPMCP device is
+allocated through the fsl_mc_portal_allocate() function.
+
+In this case, the call to fsl_mc_portal_allocate() will fail with -EINVAL
+when trying to add a device link between the root DPRC (consumer) and
+the newly allocated DPMCP device (supplier). This is because the DPMCP
+is a dependent of the DPRC device (the bus).
+
+Fix this by not adding a device link in case the DPMCP is allocated for
+the root DPRC's usage.
+
+Fixes: afb77422819f ("bus: fsl-mc: automatically add a device_link on fsl_mc_[portal,object]_allocate")
+Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20250408105814.2837951-3-ioana.ciornei@nxp.com
+Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/fsl-mc/mc-io.c | 19 +++++++++++++------
+ 1 file changed, 13 insertions(+), 6 deletions(-)
+
+--- a/drivers/bus/fsl-mc/mc-io.c
++++ b/drivers/bus/fsl-mc/mc-io.c
+@@ -214,12 +214,19 @@ int __must_check fsl_mc_portal_allocate(
+ if (error < 0)
+ goto error_cleanup_resource;
+
+- dpmcp_dev->consumer_link = device_link_add(&mc_dev->dev,
+- &dpmcp_dev->dev,
+- DL_FLAG_AUTOREMOVE_CONSUMER);
+- if (!dpmcp_dev->consumer_link) {
+- error = -EINVAL;
+- goto error_cleanup_mc_io;
++ /* If the DPRC device itself tries to allocate a portal (usually for
++ * UAPI interaction), don't add a device link between them since the
++ * DPMCP device is an actual child device of the DPRC and a reverse
++ * dependency is not allowed.
++ */
++ if (mc_dev != mc_bus_dev) {
++ dpmcp_dev->consumer_link = device_link_add(&mc_dev->dev,
++ &dpmcp_dev->dev,
++ DL_FLAG_AUTOREMOVE_CONSUMER);
++ if (!dpmcp_dev->consumer_link) {
++ error = -EINVAL;
++ goto error_cleanup_mc_io;
++ }
+ }
+
+ *new_mc_io = mc_io;
--- /dev/null
+From c78230ad34f82c6c0e0e986865073aeeef1f5d30 Mon Sep 17 00:00:00 2001
+From: Wan Junjie <junjie.wan@inceptio.ai>
+Date: Tue, 8 Apr 2025 13:58:11 +0300
+Subject: bus: fsl-mc: fix GET/SET_TAILDROP command ids
+
+From: Wan Junjie <junjie.wan@inceptio.ai>
+
+commit c78230ad34f82c6c0e0e986865073aeeef1f5d30 upstream.
+
+Command ids for taildrop get/set can not pass the check when they are
+using from the restool user space utility. Correct them according to the
+user manual.
+
+Fixes: d67cc29e6d1f ("bus: fsl-mc: list more commands as accepted through the ioctl")
+Signed-off-by: Wan Junjie <junjie.wan@inceptio.ai>
+Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
+Link: https://lore.kernel.org/r/20250408105814.2837951-4-ioana.ciornei@nxp.com
+Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/fsl-mc/fsl-mc-uapi.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/bus/fsl-mc/fsl-mc-uapi.c
++++ b/drivers/bus/fsl-mc/fsl-mc-uapi.c
+@@ -275,13 +275,13 @@ static struct fsl_mc_cmd_desc fsl_mc_acc
+ .size = 8,
+ },
+ [DPSW_GET_TAILDROP] = {
+- .cmdid_value = 0x0A80,
++ .cmdid_value = 0x0A90,
+ .cmdid_mask = 0xFFF0,
+ .token = true,
+ .size = 14,
+ },
+ [DPSW_SET_TAILDROP] = {
+- .cmdid_value = 0x0A90,
++ .cmdid_value = 0x0A80,
+ .cmdid_mask = 0xFFF0,
+ .token = true,
+ .size = 24,
--- /dev/null
+From 4d92e7c5ccadc79764674ffc2c88d329aabbb7e0 Mon Sep 17 00:00:00 2001
+From: Jeffrey Hugo <quic_jhugo@quicinc.com>
+Date: Fri, 28 Mar 2025 10:35:26 -0600
+Subject: bus: mhi: host: Fix conflict between power_up and SYSERR
+
+From: Jeff Hugo <quic_jhugo@quicinc.com>
+
+commit 4d92e7c5ccadc79764674ffc2c88d329aabbb7e0 upstream.
+
+When mhi_async_power_up() enables IRQs, it is possible that we could
+receive a SYSERR notification from the device if the firmware has crashed
+for some reason. Then the SYSERR notification queues a work item that
+cannot execute until the pm_mutex is released by mhi_async_power_up().
+
+So the SYSERR work item will be pending. If mhi_async_power_up() detects
+the SYSERR, it will handle it. If the device is in PBL, then the PBL state
+transition event will be queued, resulting in a work item after the
+pending SYSERR work item. Once mhi_async_power_up() releases the pm_mutex,
+the SYSERR work item can run. It will blindly attempt to reset the MHI
+state machine, which is the recovery action for SYSERR. PBL/SBL are not
+interrupt driven and will ignore the MHI Reset unless SYSERR is actively
+advertised. This will cause the SYSERR work item to timeout waiting for
+reset to be cleared, and will leave the host state in SYSERR processing.
+The PBL transition work item will then run, and immediately fail because
+SYSERR processing is not a valid state for PBL transition.
+
+This leaves the device uninitialized.
+
+This issue has a fairly unique signature in the kernel log:
+
+ mhi mhi3: Requested to power ON
+ Qualcomm Cloud AI 100 0000:36:00.0: Fatal error received from
+ device. Attempting to recover
+ mhi mhi3: Power on setup success
+ mhi mhi3: Device failed to exit MHI Reset state
+ mhi mhi3: Device MHI is not in valid state
+
+We cannot remove the SYSERR handling from mhi_async_power_up() because the
+device may be in the SYSERR state, but we missed the notification as the
+irq was fired before irqs were enabled. We also can't queue the SYSERR work
+item from mhi_async_power_up() if SYSERR is detected because that may
+result in a duplicate work item, and cause the same issue since the
+duplicate item will blindly issue MHI reset even if SYSERR is no longer
+active.
+
+Instead, add a check in the SYSERR work item to make sure that MHI reset is
+only issued if the device is in SYSERR state for PBL or SBL EEs.
+
+Fixes: a6e2e3522f29 ("bus: mhi: core: Add support for PM state transitions")
+Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
+Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Reviewed-by: Troy Hanson <quic_thanson@quicinc.com>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20250328163526.3365497-1-jeff.hugo@oss.qualcomm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/mhi/host/pm.c | 18 +++++++++++++++++-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+--- a/drivers/bus/mhi/host/pm.c
++++ b/drivers/bus/mhi/host/pm.c
+@@ -586,6 +586,7 @@ static void mhi_pm_sys_error_transition(
+ struct mhi_cmd *mhi_cmd;
+ struct mhi_event_ctxt *er_ctxt;
+ struct device *dev = &mhi_cntrl->mhi_dev->dev;
++ bool reset_device = false;
+ int ret, i;
+
+ dev_dbg(dev, "Transitioning from PM state: %s to: %s\n",
+@@ -614,8 +615,23 @@ static void mhi_pm_sys_error_transition(
+ /* Wake up threads waiting for state transition */
+ wake_up_all(&mhi_cntrl->state_event);
+
+- /* Trigger MHI RESET so that the device will not access host memory */
+ if (MHI_REG_ACCESS_VALID(prev_state)) {
++ /*
++ * If the device is in PBL or SBL, it will only respond to
++ * RESET if the device is in SYSERR state. SYSERR might
++ * already be cleared at this point.
++ */
++ enum mhi_state cur_state = mhi_get_mhi_state(mhi_cntrl);
++ enum mhi_ee_type cur_ee = mhi_get_exec_env(mhi_cntrl);
++
++ if (cur_state == MHI_STATE_SYS_ERR)
++ reset_device = true;
++ else if (cur_ee != MHI_EE_PBL && cur_ee != MHI_EE_SBL)
++ reset_device = true;
++ }
++
++ /* Trigger MHI RESET so that the device will not access host memory */
++ if (reset_device) {
+ u32 in_reset = -1;
+ unsigned long timeout = msecs_to_jiffies(mhi_cntrl->timeout_ms);
+
--- /dev/null
+From db22720545207f734aaa9d9f71637bfc8b0155e0 Mon Sep 17 00:00:00 2001
+From: Brett Werling <brett.werling@garmin.com>
+Date: Thu, 12 Jun 2025 14:18:25 -0500
+Subject: can: tcan4x5x: fix power regulator retrieval during probe
+
+From: Brett Werling <brett.werling@garmin.com>
+
+commit db22720545207f734aaa9d9f71637bfc8b0155e0 upstream.
+
+Fixes the power regulator retrieval in tcan4x5x_can_probe() by ensuring
+the regulator pointer is not set to NULL in the successful return from
+devm_regulator_get_optional().
+
+Fixes: 3814ca3a10be ("can: tcan4x5x: tcan4x5x_can_probe(): turn on the power before parsing the config")
+Signed-off-by: Brett Werling <brett.werling@garmin.com>
+Link: https://patch.msgid.link/20250612191825.3646364-1-brett.werling@garmin.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/m_can/tcan4x5x-core.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/can/m_can/tcan4x5x-core.c
++++ b/drivers/net/can/m_can/tcan4x5x-core.c
+@@ -310,10 +310,11 @@ static int tcan4x5x_can_probe(struct spi
+ priv = cdev_to_priv(mcan_class);
+
+ priv->power = devm_regulator_get_optional(&spi->dev, "vsup");
+- if (PTR_ERR(priv->power) == -EPROBE_DEFER) {
+- ret = -EPROBE_DEFER;
+- goto out_m_can_class_free_dev;
+- } else {
++ if (IS_ERR(priv->power)) {
++ if (PTR_ERR(priv->power) == -EPROBE_DEFER) {
++ ret = -EPROBE_DEFER;
++ goto out_m_can_class_free_dev;
++ }
+ priv->power = NULL;
+ }
+
--- /dev/null
+From 72386d5245b249f5a0a8fabb881df7ad947b8ea4 Mon Sep 17 00:00:00 2001
+From: Dennis Marttinen <twelho@welho.tech>
+Date: Thu, 29 May 2025 17:45:12 +0000
+Subject: ceph: set superblock s_magic for IMA fsmagic matching
+
+From: Dennis Marttinen <twelho@welho.tech>
+
+commit 72386d5245b249f5a0a8fabb881df7ad947b8ea4 upstream.
+
+The CephFS kernel driver forgets to set the filesystem magic signature in
+its superblock. As a result, IMA policy rules based on fsmagic matching do
+not apply as intended. This causes a major performance regression in Talos
+Linux [1] when mounting CephFS volumes, such as when deploying Rook Ceph
+[2]. Talos Linux ships a hardened kernel with the following IMA policy
+(irrelevant lines omitted):
+
+[...]
+dont_measure fsmagic=0xc36400 # CEPH_SUPER_MAGIC
+[...]
+measure func=FILE_CHECK mask=^MAY_READ euid=0
+measure func=FILE_CHECK mask=^MAY_READ uid=0
+[...]
+
+Currently, IMA compares 0xc36400 == 0x0 for CephFS files, resulting in all
+files opened with O_RDONLY or O_RDWR getting measured with SHA512 on every
+open(2):
+
+10 69990c87e8af323d47e2d6ae4... ima-ng sha512:<hash> /data/cephfs/test-file
+
+Since O_WRONLY is rare, this results in an order of magnitude lower
+performance than expected for practically all file operations. Properly
+setting CEPH_SUPER_MAGIC in the CephFS superblock resolves the regression.
+
+Tests performed on a 3x replicated Ceph v19.3.0 cluster across three
+i5-7200U nodes each equipped with one Micron 7400 MAX M.2 disk (BlueStore)
+and Gigabit ethernet, on Talos Linux v1.10.2:
+
+FS-Mark 3.3
+Test: 500 Files, Empty
+Files/s > Higher Is Better
+6.12.27-talos . 16.6 |====
++twelho patch . 208.4 |====================================================
+
+FS-Mark 3.3
+Test: 500 Files, 1KB Size
+Files/s > Higher Is Better
+6.12.27-talos . 15.6 |=======
++twelho patch . 118.6 |====================================================
+
+FS-Mark 3.3
+Test: 500 Files, 32 Sub Dirs, 1MB Size
+Files/s > Higher Is Better
+6.12.27-talos . 12.7 |===============
++twelho patch . 44.7 |=====================================================
+
+IO500 [3] 2fcd6d6 results (benchmarks within variance omitted):
+
+| IO500 benchmark | 6.12.27-talos | +twelho patch | Speedup |
+|-------------------|----------------|----------------|-----------|
+| mdtest-easy-write | 0.018524 kIOPS | 1.135027 kIOPS | 6027.33 % |
+| mdtest-hard-write | 0.018498 kIOPS | 0.973312 kIOPS | 5161.71 % |
+| ior-easy-read | 0.064727 GiB/s | 0.155324 GiB/s | 139.97 % |
+| mdtest-hard-read | 0.018246 kIOPS | 0.780800 kIOPS | 4179.29 % |
+
+This applies outside of synthetic benchmarks as well, for example, the time
+to rsync a 55 MiB directory with ~12k of mostly small files drops from an
+unusable 10m5s to a reasonable 26s (23x the throughput).
+
+[1]: https://www.talos.dev/
+[2]: https://www.talos.dev/v1.10/kubernetes-guides/configuration/ceph-with-rook/
+[3]: https://github.com/IO500/io500
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Dennis Marttinen <twelho@welho.tech>
+Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/super.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ceph/super.c
++++ b/fs/ceph/super.c
+@@ -1136,6 +1136,7 @@ static int ceph_set_super(struct super_b
+ s->s_time_min = 0;
+ s->s_time_max = U32_MAX;
+ s->s_flags |= SB_NODIRATIME | SB_NOATIME;
++ s->s_magic = CEPH_SUPER_MAGIC;
+
+ ret = set_anon_super_fc(s, fc);
+ if (ret != 0)
--- /dev/null
+From 37fb58a7273726e59f9429c89ade5116083a213d Mon Sep 17 00:00:00 2001
+From: Chen Ridong <chenridong@huawei.com>
+Date: Wed, 18 Jun 2025 07:32:17 +0000
+Subject: cgroup,freezer: fix incomplete freezing when attaching tasks
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Chen Ridong <chenridong@huawei.com>
+
+commit 37fb58a7273726e59f9429c89ade5116083a213d upstream.
+
+An issue was found:
+
+ # cd /sys/fs/cgroup/freezer/
+ # mkdir test
+ # echo FROZEN > test/freezer.state
+ # cat test/freezer.state
+ FROZEN
+ # sleep 1000 &
+ [1] 863
+ # echo 863 > test/cgroup.procs
+ # cat test/freezer.state
+ FREEZING
+
+When tasks are migrated to a frozen cgroup, the freezer fails to
+immediately freeze the tasks, causing the cgroup to remain in the
+"FREEZING".
+
+The freeze_task() function is called before clearing the CGROUP_FROZEN
+flag. This causes the freezing() check to incorrectly return false,
+preventing __freeze_task() from being invoked for the migrated task.
+
+To fix this issue, clear the CGROUP_FROZEN state before calling
+freeze_task().
+
+Fixes: f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
+Cc: stable@vger.kernel.org # v6.1+
+Reported-by: Zhong Jiawei <zhongjiawei1@huawei.com>
+Signed-off-by: Chen Ridong <chenridong@huawei.com>
+Acked-by: Michal Koutný <mkoutny@suse.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/cgroup/legacy_freezer.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/kernel/cgroup/legacy_freezer.c
++++ b/kernel/cgroup/legacy_freezer.c
+@@ -189,13 +189,12 @@ static void freezer_attach(struct cgroup
+ if (!(freezer->state & CGROUP_FREEZING)) {
+ __thaw_task(task);
+ } else {
+- freeze_task(task);
+-
+ /* clear FROZEN and propagate upwards */
+ while (freezer && (freezer->state & CGROUP_FROZEN)) {
+ freezer->state &= ~CGROUP_FROZEN;
+ freezer = parent_freezer(freezer);
+ }
++ freeze_task(task);
+ }
+ }
+
media-uvcvideo-return-the-number-of-processed-controls.patch
media-uvcvideo-send-control-events-for-partial-succeeds.patch
media-uvcvideo-fix-deferred-probing-error.patch
+arm-9447-1-arm-memremap-fix-arch_memremap_can_ram_remap.patch
+arm-omap-pmic-cpcap-do-not-mess-around-without-cpcap-or-omap4.patch
+bus-mhi-host-fix-conflict-between-power_up-and-syserr.patch
+can-tcan4x5x-fix-power-regulator-retrieval-during-probe.patch
+ceph-set-superblock-s_magic-for-ima-fsmagic-matching.patch
+cgroup-freezer-fix-incomplete-freezing-when-attaching-tasks.patch
+ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.patch
+bus-fsl-mc-do-not-add-a-device-link-for-the-uapi-used-dpmcp-device.patch
+bus-fsl-mc-fix-get-set_taildrop-command-ids.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
