FAILED: patch "[PATCH] ASoC: cs35l56: Fix race between kexec and" failed to apply to 7.2-stable tree

The patch below does not apply to the 7.2-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-7.2.y
git checkout FETCH_HEAD
git cherry-pick -x 883e78c9e6007c91be96e99a36c35baf41bc8ed5
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026091611-legged-other-642b@gregkh' --subject-prefix 'PATCH 7.2.y' 'HEAD^..'

Possible dependencies:

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 883e78c9e6007c91be96e99a36c35baf41bc8ed5 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <[email protected]>
Date: Mon, 7 Sep 2026 10:36:45 +0100
Subject: [PATCH] ASoC: cs35l56: Fix race between kexec and
snd_soc_register_component()

Use a reboot notifier and a mutex to prevent snd_soc_register_component() from racing with a kexec reboot. This prevents snd_soc_register_component() from manipulating device lists while device_shutdown() is walking them.

Commit 1d80a4792f1de ("ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration") moved snd_soc_register_component() out of probe() into a workqueue item. See the description in that commit for a detailed explanation.

That change introduces a race between snd_soc_register_component() and kexec. The reboot notifier and mutex prevent the shutdown race.

There is one remaining race with KEXEC_JUMP because it does not invoke reboot notifiers or freeze freezable workqueues. But KEXEC_JUMP is rarely used and is supported on only two architectures (x86 and SuperH). It does not appear to be enabled by default in any distro. It is also unlikely there will be a KEXEC_JUMP before snd_soc_register_component() has had the opportunity to execute. Fixing this can be deferred to a future patch.

index 890429ab0dfb..35d210626627 100644
@@ -18,9 +18,11 @@
 #include <linux/interrupt.h>
 #include <linux/math.h>
 #include <linux/module.h>
+#include <linux/mutex.h>
 #include <linux/pm.h>
 #include <linux/pm_runtime.h>
 #include <linux/property.h>
+#include <linux/reboot.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>

@@ -37,6 +39,13 @@
 #include "wm_adsp.h"
 #include "cs35l56.h"
 
+/*
+ * snd_soc_register_component() can call component_probe() on all instances
+ * in a card, so deferred registration must be protected across all instances.
+ */
+static DEFINE_MUTEX(cs35l56_component_register_lock);
+static bool cs35l56_shutting_down;
+
 void cs35l56_mask_soundwire_interrupts(struct cs35l56_private *cs35l56)
 {
 	 /*

@@ -1957,6 +1966,11 @@ static void cs35l56_component_register_work(struct work_struct *work)
 						       component_register_work);
 	int ret;
 
+	guard(mutex)(&cs35l56_component_register_lock);
+
+	if (cs35l56_shutting_down)
+		return;
+
 	PM_RUNTIME_ACQUIRE_AUTOSUSPEND(cs35l56->base.dev, pm_err);
 	ret = PM_RUNTIME_ACQUIRE_ERR(&pm_err);
 	if (ret) {

@@ -2217,6 +2231,37 @@ EXPORT_NS_GPL_DEV_PM_OPS(cs35l56_pm_ops_i2c_spi, SND_SOC_CS35L56_CORE) = {
 };
 #endif
 
+static int cs35l56_reboot_notify(struct notifier_block *nb,
+				 unsigned long action, void *data)
+{
+	guard(mutex)(&cs35l56_component_register_lock);
+	cs35l56_shutting_down = true;
+
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block cs35l56_reboot_notifier = {
+	.notifier_call = cs35l56_reboot_notify,
+};
+
+static int __init cs35l56_modinit(void)
+{
+	/*
+	 * Use reboot notifier to prevent race between shutdown and
+	 * snd_soc_register_component(). Driver shutdown() callback would
+	 * run too late, after device_shutdown() is already walking the
+	 * device list that component registration can modify.
+	 */
+	return register_reboot_notifier(&cs35l56_reboot_notifier);
+}
+module_init(cs35l56_modinit);
+
+static void __exit cs35l56_modexit(void)
+{
+	unregister_reboot_notifier(&cs35l56_reboot_notifier);
+}
+module_exit(cs35l56_modexit);
+
 MODULE_DESCRIPTION("ASoC CS35L56 driver");
 MODULE_IMPORT_NS("SND_SOC_CS35L56_SHARED");
 MODULE_IMPORT_NS("SND_SOC_CS_AMP_LIB");

Hmm, yes. That patch (and the two bugfixes before it) are on top of some other changes in Mark's tree that are not fixes. They aren't related but they change the code enough to cause a conflict. (Unfortunately the bugs were reported after those prior three patches had already been sent).

Question:
Have the two prior bugfix commits applied to 7.2-stable? This failed one is the last of three bugfix commits:

883e78c9e6007 ASoC: cs35l56: Fix race between kexec and snd_soc_register_component() 1d80a4792f1de ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration fbf2c660bac86 ASoC: cs35l56: Fix pm_runtime imbalance if suspending before first attach

What to do really depends on whether all three failed to apply or it's only this last one.

From my naive testing all three fail to apply to stable/linux-7.2.y, but I've only received this "failed to apply" email for the 3rd patch.

Two of the three are already queued for 7.2:

883e78c9e6007 ("ASoC: cs35l56: Fix race between kexec and
snd_soc_register_component()")
1d80a4792f1de ("ASoC: cs35l56: Fix probe deadlock waiting for
SoundWire enumeration")

[...]

This one is the gap: it isn't in 7.2-stable, and it isn't queued for any stable tree. Its context doesn't exist on 7.2 either - cs35l56_sdw_system_suspend() there still calls cs35l56_disable_sdw_interrupts() rather than cs35l56_mask_soundwire_interrupts() - so it needs the same kind of adjustment the other two got.

If you can send a 7.2-adjusted backport of fbf2c660bac86 to [email protected] with the original commit id, I'll queue it up.

Right, all three need adaptation; two of them have already been adapted and queued, which is why you only saw one notice.

Thanks,
Sasha