kernel.git/include/sound/pcm.h, branch linux-5.16.y

ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock

2022-04-08T12:05:27Z

commit bc55cfd5718c7c23e5524582e9fa70b4d10f2433 upstream. syzbot caught a potential deadlock between the PCM runtime->buffer_mutex and the mm->mmap_lock. It was brought by the recent fix to cover the racy read/write and other ioctls, and in that commit, I overlooked a (hopefully only) corner case that may take the revert lock, namely, the OSS mmap. The OSS mmap operation exceptionally allows to re-configure the parameters inside the OSS mmap syscall, where mm->mmap_mutex is already held. Meanwhile, the copy_from/to_user calls at read/write operations also take the mm->mmap_lock internally, hence it may lead to a AB/BA deadlock. A similar problem was already seen in the past and we fixed it with a refcount (in commit b248371628aa). The former fix covered only the call paths with OSS read/write and OSS ioctls, while we need to cover the concurrent access via both ALSA and OSS APIs now. This patch addresses the problem above by replacing the buffer_mutex lock in the read/write operations with a refcount similar as we've used for OSS. The new field, runtime->buffer_accessing, keeps the number of concurrent read/write operations. Unlike the former buffer_mutex protection, this protects only around the copy_from/to_user() calls; the other codes are basically protected by the PCM stream lock. The refcount can be a negative, meaning blocked by the ioctls. If a negative value is seen, the read/write aborts with -EBUSY. In the ioctl side, OTOH, they check this refcount, too, and set to a negative value for blocking unless it's already being accessed. Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com Fixes: dca947d4d26d ("ALSA: pcm: Fix races among concurrent read/write and buffer changes") Cc: Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Fix races among concurrent hw_params and hw_free calls

2022-03-28T07:59:53Z

commit 92ee3c60ec9fe64404dc035e7c41277d74aa26cb upstream. Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls. This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params and hw_free ioctl code paths. Along with it, the both functions are slightly modified (the mmap_count check is moved into the state-check block) for code simplicity. Reported-by: Hu Jiahui Cc: Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Allow exact buffer preallocation

2021-08-04T06:08:06Z

A few drivers want to have rather the exact buffer preallocation at the driver probe time and keep using it for the whole operations without allowing dynamic buffer allocation. For satisfying the demands, this patch extends the managed buffer allocation API slightly. Namely, when 0 is passed to max argument of the allocation helper functions snd_pcm_set_managed_buffer*(), it treats as if the fixed size allocation of the given size. If the pre-allocation fails in this mode, the function returns now -ENOMEM. Otherwise, i.e. max argument is non-zero, the function never returns -ENOMEM but tries to fall back to the smaller chunks and allows the dynamic allocation later -- which is still the default behavior until now. For more intuitive use, also two new helpers are added for handling the fixed size buffer allocation, too: snd_pcm_set_fixed_buffer() and snd_pcm_set_fixed_buffer_all(). Acked-by: Mark Brown Link: https://lore.kernel.org/r/20210802072815.13551-4-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: core: Abstract memory alloc helpers

2021-06-10T08:15:21Z

This patch introduces the ops table to each memory allocation type (SNDRV_DMA_TYPE_XXX) and abstract the handling for the better code management. Then we get separate the page allocation, release and other tasks for each type, especially for the SG buffer. Each buffer type has now callbacks in the struct snd_malloc_ops, and the common helper functions call those ops accordingly. The former inline code that is specific to SG-buffer is moved into the local sgbuf.c, and we can simplify the PCM code without details of memory handling. Link: https://lore.kernel.org/r/20210609162551.7842-4-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: core: Drop snd_sgbuf_get_ptr()

2021-06-10T08:15:21Z

snd_sgbuf_get_ptr() and its sibling snd_pcm_sgbuf_get_ptr() are no longer used by any drivers. Let's drop them. Link: https://lore.kernel.org/r/20210609162551.7842-3-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: pcm: add snd_pcm_period_elapsed() variant without acquiring lock of PCM substream

2021-06-10T07:49:54Z

Current implementation of ALSA PCM core has a kernel API, snd_pcm_period_elapsed(), for drivers to queue event to awaken processes from waiting for available frames. The function voluntarily acquires lock of PCM substream, therefore it is not called in process context for any PCM operation since the lock is already acquired. It is convenient for packet-oriented driver, at least for drivers to audio and music unit in IEEE 1394 bus. The drivers are allowed by Linux FireWire subsystem to process isochronous packets queued till recent isochronous cycle in process context in any time. This commit adds snd_pcm_period_elapsed() variant, snd_pcm_period_elapsed_without_lock(), for drivers to queue the event in the process context. Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210610031733.56297-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: pcm: One more dependency for hw constraints

2021-01-23T15:59:24Z

The fix for a long-standing USB-audio bug required one more dependency variable to be added to the hw constraints. Unfortunately I didn't realize at debugging that the new addition may result in the overflow of the dependency array of each snd_pcm_hw_rule (up to three plus a sentinel), because USB-audio driver adds one more dependency only for a certain device and bus, hence it works as is for many devices. But in a bad case, a simple open always results in -EINVAL (with kernel WARNING if CONFIG_SND_DEBUG is set) no matter what is passed. Since the dependencies are real and unavoidable (USB-audio restricts the hw_params per looping over the format/rate/channels combos), the only good solution seems to raise the bar for one more dependency for snd_pcm_hw_rule -- so does this patch: now the hw constraint dependencies can be up to four. Fixes: 506c203cc3de ("ALSA: usb-audio: Fix hw constraints dependencies") Reported-by: Jamie Heilman Link: https://lore.kernel.org/r/20210123155730.22576-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: fix kernel-doc markups

2020-10-26T14:26:31Z

Kernel-doc markups should use this format: identifier - description There is a common comment marked, instead, with kernel-doc notation. Some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab Acked-by: Mark Brown Link: https://lore.kernel.org/r/535182d6f55d7a7de293dda9676df68f5f60afc6.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Takashi Iwai

Merge tag 'asoc-v5.7' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2020-03-30T11:43:00Z

ASoC: Updates for v5.7 This is a very big update for the core since Morimoto-san has been rather busy continuing his refactorings to clean up a lot of the cruft that we have accumilated over the years. We've also gained several new drivers, including initial (but still not complete) parts of the Intel SoundWire support. - Lots of refactorings to modernize the code from Morimoto-san. - Conversion of SND_SOC_ALL_CODECS to use imply from Geert Uytterhoeven. - Continued refactoring and fixing of the Intel support. - Soundwire and more advanced clocking support for Realtek RT5682. - Support for amlogic GX, Meson 8, Meson 8B and T9015 DAC, Broadcom DSL/PON, Ingenic JZ4760 and JZ4770, Realtek RL6231, and TI TAS2563 and TLV320ADCX140.

ALSA: pcm: Add a standalone version of snd_pcm_limit_hw_rates

2020-03-06T14:24:09Z

It can be useful to derive min/max rates of a snd_pcm_hardware without having a snd_pcm_runtime, such as before constructing an ASoC DAI link. Create a new helper that takes a pointer to a snd_pcm_hardware directly, and refactor the original function as a wrapper around it, to avoid needing to update any call sites. Signed-off-by: Samuel Holland Reviewed-by: Takashi Iwai Link: https://lore.kernel.org/r/20200305051143.60691-2-samuel@sholland.org Signed-off-by: Mark Brown