kernel/linux.git/sound/core/init.c, branch v5.15.209

ALSA: core: add isascii() check to card ID generator

2024-10-17T13:11:36+00:00

commit d278a9de5e1837edbe57b2f1f95a104ff6c84846 upstream. The card identifier should contain only safe ASCII characters. The isalnum() returns true also for characters for non-ASCII characters. Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4135 Link: https://lore.kernel.org/linux-sound/yk3WTvKkwheOon_LzZlJ43PPInz6byYfBzpKkbasww1yzuiMRqn7n6Y8vZcXB-xwFCu_vb8hoNjv7DTNwH5TWjpEuiVsyn9HPCEXqwF4120=@protonmail.com/ Cc: stable@vger.kernel.org Reported-by: Barnabás Pőcze Signed-off-by: Jaroslav Kysela Link: https://patch.msgid.link/20241002194649.1944696-1-perex@perex.cz Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: Fix deadlocks with kctl removals at disconnection

2024-06-16T11:39:13+00:00

commit 87988a534d8e12f2e6fc01fe63e6c1925dc5307c upstream. In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218816 Cc: Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20240510101424.6279-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: core: Fix NULL module pointer assignment at card init

2024-06-16T11:39:13+00:00

commit 39381fe7394e5eafac76e7e9367e7351138a29c1 upstream. The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare. Fixes: 81033c6b584b ("ALSA: core: Warn on empty module") Reported-by: Xu Yang Closes: https://lore.kernel.org/r/20240520170349.2417900-1-xu.yang_2@nxp.com Cc: Signed-off-by: Takashi Iwai Tested-by: Xu Yang Link: https://lore.kernel.org/r/20240522070442.17786-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman

ALSA: core: Fix double-free at snd_card_new()

2022-09-28T09:11:40+00:00

commit c3afa2a402d1ecefa59f88d55d9e765f52f75bd9 upstream. During the code change to add the support for devres-managed card instance, we put an explicit kfree(card) call at the error path in snd_card_new(). This is needed for the early error path before the card is initialized with the device, but is rather superfluous and causes a double-free at the error path after the card instance is initialized, as the destructor of the card object already contains a kfree() call. This patch fixes the double-free situation by removing the superfluous kfree(). Meanwhile we need to call kfree() explicitly for the early error path, so it's added there instead. Fixes: e8ad415b7a55 ("ALSA: core: Add managed card creation") Reported-by: Rondreis Cc: Link: https://lore.kernel.org/r/CAB7eexL1zBnB636hwS27d-LdPYZ_R1-5fJS_h=ZbCWYU=UPWJg@mail.gmail.com Link: https://lore.kernel.org/r/20220919123516.28222-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: core: Add snd_card_free_on_error() helper

2022-04-20T07:34:05+00:00

commit fee2b871d8d6389c9b4bdf9346a99ccc1c98c9b8 upstream. This is a small helper function to handle the error path more easily when an error happens during the probe for the device with the device-managed card. Since devres releases in the reverser order of the creations, usually snd_card_free() gets called at the last in the probe error path unless it already reached snd_card_register() calls. Due to this nature, when a driver expects the resource releases in card->private_free, this might be called too lately. As a workaround, one should call the probe like: static int __some_probe(...) { // do real probe.... } static int some_probe(...) { return snd_card_free_on_error(dev, __some_probe(dev, ...)); } so that the snd_card_free() is called explicitly at the beginning of the error path from the probe. This function will be used in the upcoming fixes to address the regressions by devres usages. Fixes: e8ad415b7a55 ("ALSA: core: Add managed card creation") Cc: Link: https://lore.kernel.org/r/20220412093141.8008-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: core: Fix double calls of snd_card_free() via devres

2021-07-31T08:36:06+00:00

At the transition to the devres-managed card release, we've put the check of double-free at trigger_card_release(). But this wasn't enough, as the code path calls snd_card_free() again, and it would lead to the doubly snd_card_free() calls. Actually the v1 patch was correct to handle this, but I forgot that corner case and moved the check to the more obvious place as I thought it's clearer. But, as usual, devils live in details. This patch corrects the check of the double-free to the right place, with a bit more comments. Fixes: e8ad415b7a55 ("ALSA: core: Add managed card creation") Link: https://lore.kernel.org/r/20210731083446.26680-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: core: Add managed card creation

2021-07-19T14:16:33+00:00

As a second step for preliminary to widen the devres usages among sound drivers, this patch adds a new ALSA core API function, snd_devm_card_new(), to create a snd_card object via devres. When a card object is created by this new function, snd_card_free() is called automatically and the card object resource gets released at the device unbinding time. However, the story isn't that simple. A caveat is that we have to call snd_card_free() at the very first of the whole resource release procedure, in order to assure that the all exposed devices on user-space are deleted and sync with processes accessing those devices before releasing resources. For achieving it, snd_card_register() adds a new devres action to trigger snd_card_free() automatically when the given card object is a "managed" one. Since usually snd_card_register() is the last step of the initialization, this should work in most cases. With all these tricks, some drivers can get rid of the whole driver remove callback code. About a bit of implementation details: the patch adds two new flags to snd_card object: managed and releasing. The former indicates that the object was created via snd_devm_card_new(), and the latter is used for avoiding the double-free of snd_card_free() calls. Both flags are fairly internal and likely uninteresting to normal users. Link: https://lore.kernel.org/r/20210715075941.23332-3-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: core: Fix assignment in if condition

2021-06-09T15:30:22+00:00

There are a few places doing assignments in if condition in ALSA core code, which is a bad coding style that may confuse readers and occasionally lead to bugs. This patch is merely for coding-style fixes, no functional changes. Link: https://lore.kernel.org/r/20210608140540.17885-54-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: core: use DEVICE_ATTR_*() macro

2021-05-28T14:32:11+00:00

Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by: YueHaibing Link: https://lore.kernel.org/r/20210526121828.8460-1-yuehaibing@huawei.com Signed-off-by: Takashi Iwai

ALSA: Drop superfluous argument from snd_power_wait()

2021-05-25T06:49:39+00:00

The power_state argument of snd_power_wait() is superfluous, receiving only SNDRV_POWER_STATE_D0. Let's drop it in all callers for simplicity. Reviewed-by: Jaroslav Kysela Acked-by: Mark Brown Link: https://lore.kernel.org/r/20210523090920.15345-6-tiwai@suse.de Signed-off-by: Takashi Iwai