From: Takashi Iwai tiwai@suse.de
[ Upstream commit 1adcbdf54f76e1004bdf71df4eb1888c26e7ad06 ]
Although the jack polling is canceled at shutdown in snd_hda_codec_shutdown(), it might be still re-triggered when the work is being processed at cancel_delayed_work_sync() call. This may result in the unexpected hardware access that should have been already disabled.
For assuring to stop the jack polling, clear codec->jackpoll_interval at shutdown.
Reported-by: Joakim Zhang joakim.zhang@cixtech.com Closes: https://lore.kernel.org/20250619020844.2974160-4-joakim.zhang@cixtech.com Tested-by: Joakim Zhang joakim.zhang@cixtech.com Signed-off-by: Takashi Iwai tiwai@suse.de Link: https://patch.msgid.link/20250623131437.10670-2-tiwai@suse.de Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## Bug Fix Analysis
The commit fixes a **race condition** during codec shutdown where jack polling work could be re-triggered even after attempting to cancel it. This is evident from the commit message: "it might be still re-triggered when the work is being processed at cancel_delayed_work_sync() call."
The race condition occurs because: 1. `cancel_delayed_work_sync()` waits for the current work to complete 2. While waiting, if the work function (`hda_jackpoll_work`) is executing, it checks `codec->jackpoll_interval` at line 635 of the original code 3. If `jackpoll_interval` is still non-zero, the work reschedules itself with `schedule_delayed_work(&codec->jackpoll_work, codec->jackpoll_interval)` at line 641 4. This creates a situation where hardware access occurs after shutdown has supposedly completed
## Code Change Analysis
The fix is **minimal and surgical** - just one line added: ```c codec->jackpoll_interval = 0; /* don't poll any longer */ ```
This is placed **before** the `cancel_delayed_work_sync()` call, ensuring that even if the work function is currently running, it won't reschedule itself because the interval check at the beginning of `hda_jackpoll_work()` will fail.
## Impact Assessment
1. **User-visible bug**: Yes - unexpected hardware access during shutdown can cause system hangs, crashes, or hardware-related issues 2. **Fix size**: Extremely small - single line addition 3. **Risk assessment**: Very low - setting a value to 0 before canceling work is a safe operation 4. **Subsystem criticality**: ALSA HD-Audio is widely used, but this specific fix is in the shutdown path 5. **Testing**: The commit has been tested by the reporter (Joakim Zhang)
## Stable Tree Criteria
This commit meets stable tree requirements: - Fixes a real bug (race condition causing unexpected hardware access) - Minimal change (1 line) - Clear fix with obvious correctness - No new features or architectural changes - Only affects the shutdown path, limiting scope - Has been tested by the bug reporter
The fix prevents potential system instability during shutdown, making it an important candidate for stable backporting.
sound/pci/hda/hda_codec.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 94b3732e6cb2..aef60044cb8a 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3040,6 +3040,7 @@ void snd_hda_codec_shutdown(struct hda_codec *codec) if (!codec->core.registered) return;
+ codec->jackpoll_interval = 0; /* don't poll any longer */ cancel_delayed_work_sync(&codec->jackpoll_work); list_for_each_entry(cpcm, &codec->pcm_list_head, list) snd_pcm_suspend_all(cpcm->pcm);