kernel/linux.git/include/sound/pcm.h, branch v7.1

ALSA: pcm: oss: use proper stream lock for runtime->state access

2026-03-16T17:05:55+00:00

__snd_pcm_set_state() writes runtime->state under the PCM stream lock. However, the OSS I/O functions snd_pcm_oss_write3(), snd_pcm_oss_read3(), snd_pcm_oss_writev3() and snd_pcm_oss_readv3() read runtime->state without holding the stream lock, only holding oss.params_lock (a different mutex that does not synchronize with the stream lock). Since __snd_pcm_set_state() is called from IRQ context (e.g., snd_pcm_period_elapsed -> snd_pcm_update_state -> __snd_pcm_xrun -> snd_pcm_stop -> snd_pcm_post_stop) while the OSS read/write paths run in process context, these are concurrent accesses that constitute a data race. Rather than using READ_ONCE()/WRITE_ONCE() barriers, introduce a snd_pcm_get_state() helper that reads runtime->state under the stream lock, matching the locking discipline used elsewhere in the PCM layer. Also export snd_pcm_set_state() for completeness. Use snd_pcm_get_state() in all four OSS I/O functions, caching the result in a local variable where the same snapshot is used for multiple comparisons to avoid taking the lock repeatedly. Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260316085047.2876451-1-zzzccc427@gmail.com Signed-off-by: Takashi Iwai

ALSA: pcm: Improve the fix for race of buffer access at PCM OSS layer

2026-01-08T07:07:54+00:00

Handle the error code from snd_pcm_buffer_access_lock() in snd_pcm_runtime_buffer_set_silence() function. Found by Alexandros Panagiotou Fixes: 93a81ca06577 ("ALSA: pcm: Fix race of buffer access at PCM OSS layer") Cc: stable@vger.kernel.org # 6.15 Signed-off-by: Jaroslav Kysela Link: https://patch.msgid.link/20260107213642.332954-1-perex@perex.cz Signed-off-by: Takashi Iwai

Merge branch 'for-linus' into for-next

2025-05-22T18:34:24+00:00

Sync with the pending 6.15 fixes. Signed-off-by: Takashi Iwai

ALSA: pcm: Fix race of buffer access at PCM OSS layer

2025-05-16T08:09:02+00:00

The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation. Reported-by: syzbot+32d4647f551007595173@syzkaller.appspotmail.com Closes: https://lore.kernel.org/68164d8e.050a0220.11da1b.0019.GAE@google.com Cc: Link: https://patch.msgid.link/20250516080817.20068-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: pcm: Remove unused snd_pcm_rate_range_to_bits

2025-05-05T10:36:29+00:00

The last use of snd_pcm_rate_range_to_bits() was removed in 2016 by commit b6b6e4d670c9 ("ASoC: topology: Fix setting of stream rates, rate_min and rate_max") Remove it. Signed-off-by: Dr. David Alan Gilbert Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250502235219.1000429-2-linux@treblig.org

ALSA: Align the syntax of iov_iter helpers with standard ones

2024-12-30T11:50:04+00:00

We introduced a couple of helpers for copying iomem over iov_iter, and the functions were formed like the former copy_from/to_user(), and the return value was adjusted to 0/-EFAULT, which made the code transition a bit easier at that time. OTOH, the standard copy_from/to_iter() functions have different argument orders and the return value, and this difference can be confusing. It's not only confusing but dangerous; actually I did write a wrong code due to that once :-< For reducing the confusion, this patch changes the syntax of those helpers to align with the standard copy_from/to_iter(). The argument order is changed and the return value is the size of copied bytes. The callers of those functions are updated accordingly, too. Link: https://patch.msgid.link/20241230114903.4959-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: pcm: Define snd_pcm_mmap_data_{open|close}() locally

2024-11-13T12:33:28+00:00

snd_pcm_mmap_data_open() and _close() are defined as inline functions in the public sound/pcm.h, but those are used only locally in pcm_native.c, hence they should be better placed there. Also, those are referred as callbacks, the useless inline is dropped. Link: https://patch.msgid.link/20241113111628.17069-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: tidyup SNDRV_PCM_TRIGGER_xxx numbering

2024-11-13T07:23:57+00:00

pcm.h has SNDRV_PCM_TRIGGER_xxx, but it is missing "2". Fixup it. Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/87ed3gsziy.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Takashi Iwai

ALSA: pcm: Fix breakage of PCM rates used for topology

2024-09-11T14:17:44+00:00

It turned out that the topology ABI takes the standard PCM rate bits as is, and it means that the recent change of the PCM rate bits would lead to the inconsistent rate values used for topology. This patch reverts the original PCM rate bit definitions while adding the new rates to the extended bits instead. This needed the change of snd_pcm_known_rates, too. And this also required to fix the handling in snd_pcm_hw_limit_rates() that blindly assumed that the list is sorted while it became unsorted now. Fixes: 090624b7dc83 ("ALSA: pcm: add more sample rate definitions") Reported-by: Pierre-Louis Bossart Closes: https://lore.kernel.org/1ab3efaa-863c-4dd0-8f81-b50fd9775fad@linux.intel.com Reviewed-by: Jaroslav Kysela Tested-by: Jerome Brunet Tested-by: Bard Liao Link: https://patch.msgid.link/20240911135756.24434-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: pcm: add more sample rate definitions

2024-09-06T07:23:54+00:00

This adds a sample rate definition for 12kHz, 24kHz and 128kHz. Admittedly, just a few drivers are currently using these sample rates but there is enough of a recurrence to justify adding a definition for them and remove some custom rate constraint code while at it. The new definitions are not added to the interval definitions, such as SNDRV_PCM_RATE_8000_44100, because it would silently add new supported rates to drivers that may or may not support them. For sure the drivers have not been tested for these new rates so it is better to leave them out of interval definitions. That being said, the added rates are multiples of well know rates families, it is very likely that a lot of devices out there actually supports them. Signed-off-by: Jerome Brunet Reviewed-by: David Rhodes Acked-by: Mark Brown Reviewed-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-1-8371948d3921@baylibre.com