From: Takashi Iwai tiwai@suse.de
[ Upstream commit ed29e073ba93f2d52832804cabdd831d5d357d33 ]
When a PCM stream is already running, one shouldn't change the DMA mode via kcontrol, which may screw up the hardware. Return -EBUSY instead.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218185 Link: https://patch.msgid.link/20250610064322.26787-1-tiwai@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## Key Reasons for Backporting:
1. **Critical Bug Fix for Race Condition**: The commit fixes a race condition where changing DMA mode via kcontrol while PCM streams are running can corrupt hardware state. Looking at the code: - The `chip->mode` field tracks active playback/capture operations using `SB_MODE_PLAYBACK` and `SB_MODE_CAPTURE` flags - The DMA mode control (`force_mode16`) affects how DMA transfers are configured - Changing this while streams are active can cause hardware inconsistencies
2. **Clear User-Visible Bug**: The commit references Bugzilla #218185, indicating this is a real user-reported issue that affects system stability and audio functionality.
3. **Minimal and Contained Fix**: The change is extremely small and focused: ```c + if (chip->mode & (SB_MODE_PLAYBACK | SB_MODE_CAPTURE)) + return -EBUSY; ``` It simply adds a check to prevent mode changes during active operations, returning -EBUSY to userspace.
4. **No Architectural Changes**: This is a straightforward defensive check that doesn't alter any core functionality or introduce new features. It only prevents an invalid operation.
5. **Low Risk of Regression**: The fix: - Only affects the SB16 sound driver - Only changes behavior when someone tries to modify DMA mode during active streaming - Returns a standard error code (-EBUSY) that applications should already handle - Doesn't affect normal audio operations
6. **Follows Stable Kernel Rules**: This perfectly matches stable kernel criteria: - Fixes a real bug that affects users - Obviously correct with no subtleties - Small change (2 lines of actual code) - Already tested in mainline - No new features added
## Technical Analysis:
From examining the code flow: - During `snd_sb16_playback_open()` and `snd_sb16_capture_open()`, the driver sets `chip->mode` flags - These flags remain set until `snd_sb16_playback_close()` and `snd_sb16_capture_close()` clear them - The `force_mode16` setting affects DMA channel selection throughout the driver - Without this fix, userspace can change `force_mode16` while DMA operations are active, potentially causing: - DMA channel mismatches - Audio corruption - System instability
This is similar to the first example commit that was backported, which also prevented operations during inappropriate states (DMA synchronization during PAUSE state).
sound/isa/sb/sb16_main.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/isa/sb/sb16_main.c b/sound/isa/sb/sb16_main.c index a9b87e159b2d1..5efbd0a41312b 100644 --- a/sound/isa/sb/sb16_main.c +++ b/sound/isa/sb/sb16_main.c @@ -703,6 +703,9 @@ static int snd_sb16_dma_control_put(struct snd_kcontrol *kcontrol, struct snd_ct unsigned char nval, oval; int change; + if (chip->mode & (SB_MODE_PLAYBACK | SB_MODE_CAPTURE)) + return -EBUSY; + nval = ucontrol->value.enumerated.item[0]; if (nval > 2) return -EINVAL;