kernel.git/sound/core/pcm_compat.c, branch linux-rolling-stable

ALSA: pcm: Relax __free() variable declarations

2026-02-26T22:59:11Z

[ Upstream commit f3d233daf011abbad2f6ebd0e545b42d2f378a4f ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: ae9213984864 ("ALSA: pcm: Use automatic cleanup of kfree()") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-4-tiwai@suse.de Signed-off-by: Sasha Levin

ALSA: pcm: Replace [audio_]tstamp_[n]sec by struct __snd_timespec in struct snd_pcm_mmap_status32

2025-06-16T06:25:27Z

To match struct __snd_pcm_mmap_status and enable reuse of snd_pcm_sync_ptr_get_user() and snd_pcm_sync_ptr_put_user() by snd_pcm_sync_ptr() replace tstamp_sec and tstamp_nsec fields by a struct __snd_timespec in struct snd_pcm_mmap_status32. Do the same with audio_tstamp_sec and audio_tstamp_nsec. This is possible because struct snd_pcm_mmap_status32 is packed and __SND_STRUCT_TIME64 is always defined for kernel which means struct __snd_timespec is always defined as: struct __snd_timespec { __s32 tv_sec; __s32 tv_nsec; }; Signed-off-by: Christophe Leroy Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/df8ea1a9aff61c3e358759b1f495bdb9fb8a3e6a.1749883041.git.christophe.leroy@csgroup.eu

ALSA: pcm: refactor copy from/to user in SNDRV_PCM_IOCTL_SYNC_PTR

2025-06-14T11:40:14Z

In an effort of optimising SNDRV_PCM_IOCTL_SYNC_PTR ioctl which is a hot path, lets first refactor the copy from and to user with macros. This is done with macros and not static inline fonctions because types differs between the different versions of snd_pcm_sync_ptr() like functions. First step is to refactor only snd_pcm_ioctl_sync_ptr_compat() and snd_pcm_ioctl_sync_ptr_x32() as it would be a performance regression for snd_pcm_sync_ptr() and snd_pcm_ioctl_sync_ptr_buggy() for now. They may be refactored after next patch. Signed-off-by: Christophe Leroy Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/f8b77932bb9ce96148ae5c3953e7ee44fa2359f8.1749883041.git.christophe.leroy@csgroup.eu

ALSA: pcm: Use guard() for PCM stream locks

2024-02-28T14:01:22Z

Define guard() usage for PCM stream locking and use it in appropriate places. The pair of snd_pcm_stream_lock() and snd_pcm_stream_unlock() can be presented with guard(pcm_stream_lock) now. Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20240227085306.9764-23-tiwai@suse.de

ALSA: pcm: Use automatic cleanup of kfree()

2024-02-23T09:57:30Z

There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). A caveat is that some allocations are memdup_user() and they return an error pointer instead of NULL. Those need special cares and the value has to be cleared with no_free_ptr() at the allocation error path. Other than that, the conversions are straightforward. No functional changes, only code refactoring. Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20240222111509.28390-2-tiwai@suse.de

ALSA: pcm: Fix missing fixup call in compat hw_refine ioctl

2023-08-29T14:03:11Z

The update of rate_num/den and msbits were factored out to fixup_unreferenced_params() function to be called explicitly after the hw_refine or hw_params procedure. It's called from snd_pcm_hw_refine_user(), but it's forgotten in the PCM compat ioctl. This ended up with the incomplete rate_num/den and msbits parameters when 32bit compat ioctl is used. This patch adds the missing call in snd_pcm_ioctl_hw_params_compat(). Reported-by: Meng_Cai@novatek.com.cn Fixes: f9a076bff053 ("ALSA: pcm: calculate non-mask/non-interval parameters always when possible") Reviewed-by: Takashi Sakamoto Reviewed-by: Jaroslav Kysela Cc: Link: https://lore.kernel.org/r/20230829134344.31588-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: pcm: Avoid reference to status->state

2022-09-27T06:44:05Z

In the PCM core and driver code, there are lots place referring to the current PCM state via runtime->status->state. This patch introduced a local PCM state in runtime itself and replaces those references with runtime->state. It has improvements in two aspects: - The reduction of a indirect access leads to more code optimization - It avoids a possible (unexpected) modification of the state via mmap of the status record The status->state is updated together with runtime->state, so that user-space can still read the current state via mmap like before, too. This patch touches only the ALSA core code. The changes in each driver will follow in later patches. Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20220926135558.26580-2-tiwai@suse.de Signed-off-by: Takashi Iwai

x86: Remove toolchain check for X32 ABI capability

2022-03-15T09:32:48Z

Commit 0bf6276392e9 ("x32: Warn and disable rather than error if binutils too old") added a small test in arch/x86/Makefile because binutils 2.22 or newer is needed to properly support elf32-x86-64. This check is no longer necessary, as the minimum supported version of binutils is 2.23, which is enforced at configuration time with scripts/min-tool-version.sh. Remove this check and replace all uses of CONFIG_X86_X32 with CONFIG_X86_X32_ABI, as two symbols are no longer necessary. [nathan: Rebase, fix up a few places where CONFIG_X86_X32 was still used, and simplify commit message to satisfy -tip requirements] Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220314194842.3452-2-nathan@kernel.org

ALSA: memalloc: Support for non-contiguous page allocation

2021-10-18T11:32:10Z

This patch adds the support for allocation of non-contiguous DMA pages in the common memalloc helper. It's another SG-buffer type, but unlike the existing one, this is directional and requires the explicit sync / invalidation of dirty pages on non-coherent architectures. For this enhancement, the following points are changed: - snd_dma_device stores the DMA direction. - snd_dma_device stores need_sync flag indicating whether the explicit sync is required or not. - A new variant of helper functions, snd_dma_alloc_dir_pages() and *_all() are introduced; the old snd_dma_alloc_pages() and *_all() kept as just wrappers with DMA_BIDIRECTIONAL. - A new helper snd_dma_buffer_sync() is introduced; this gets called in the appropriate places. - A new allocation type, SNDRV_DMA_TYPE_NONCONTIG, is introduced. When the driver allocates pages with this new type, and it may require the SNDRV_PCM_INFO_EXPLICIT_SYNC flag set to the PCM hardware.info for taking the full control of PCM applptr and hwptr changes (that implies disabling the mmap of control/status data). When the buffer allocation is managed by snd_pcm_set_managed_buffer(), this flag is automatically set depending on the result of dma_need_sync() internally. Otherwise, if the buffer is managed manually, the driver has to set the flag explicitly, too. The explicit sync between CPU and device for non-coherent memory is performed at the points before and after read/write transfer as well as the applptr/hwptr syncptr ioctl. In the case of mmap mode, user-space is supposed to call the syncptr ioctl with the hwptr flag to update and fetch the status at first; this corresponds to CPU-sync. Then user-space advances the applptr via syncptr ioctl again with applptr flag, and this corresponds to the device sync with flushing. Other than the DMA direction and the explicit sync, the usage of this new buffer type is almost equivalent with the existing SNDRV_DMA_TYPE_DEV_SG; you can get the page and the address via snd_sgbuf_get_page() and snd_sgbuf_get_addr(), also calculate the continuous pages via snd_sgbuf_get_chunk_size(). For those SG-page handling, the non-contig type shares the same ops with the vmalloc handler. As we do always vmap the SG pages at first, the actual address can be deduced from the vmapped address easily without iterating the SG-list. Link: https://lore.kernel.org/r/20211017074859.24112-2-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl

2021-10-11T16:10:47Z

Michael Forney reported an incorrect padding type that was defined in the commit 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") for PCM control mmap data. His analysis is correct, and this caused the misplacements of PCM control data on 32bit arch and 32bit compat mode. The bug is that the __pad2 definition in __snd_pcm_mmap_control64 struct was wrongly with __pad_before_uframe, which should have been __pad_after_uframe instead. This struct is used in SYNC_PTR ioctl and control mmap. Basically this bug leads to two problems: - The offset of avail_min field becomes wrong, it's placed right after appl_ptr without padding on little-endian - When appl_ptr and avail_min are read as 64bit values in kernel side, the values become either zero or corrupted (mixed up) One good news is that, because both user-space and kernel misunderstand the wrong offset, at least, 32bit application running on 32bit kernel works as is. Also, 64bit applications are unaffected because the padding size is zero. The remaining problem is the 32bit compat mode; as mentioned in the above, avail_min is placed right after appl_ptr on little-endian archs, 64bit kernel reads bogus values for appl_ptr updates, which may lead to streaming bugs like jumping, XRUN or whatever unexpected. (However, we haven't heard any serious bug reports due to this over years, so practically seen, it's fairly safe to assume that the impact by this bug is limited.) Ideally speaking, we should correct the wrong mmap status control definition. But this would cause again incompatibility with the existing binaries, and fixing it (e.g. by renumbering ioctls) would be really messy. So, as of this patch, we only correct the behavior of 32bit compat mode and keep the rest as is. Namely, the SYNC_PTR ioctl is now handled differently in compat mode to read/write the 32bit values at the right offsets. The control mmap of 32bit apps on 64bit kernels has been already disabled (which is likely rather an overlook, but this worked fine at this time :), so covering SYNC_PTR ioctl should suffice as a fallback. Fixes: 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") Reported-by: Michael Forney Reviewed-by: Arnd Bergmann Cc: Cc: Rich Felker Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.de Signed-off-by: Takashi Iwai