Re: [RFC PATCH v5 2/2] ALSA: usb-audio: bind the Topping M62's vendor controls

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] A race condition exists between devres cleanup and the component framework during device unbind, which allows the WARN_ON(!tm) in topping_master_bind() to be trivially triggered.
--

commit fc33d2a046de2359ba0a5826832474e168d41b39
Author: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>

ALSA: usb-audio: bind the Topping M62's vendor controls

This commit adds a component master for the Topping M62 sound card,
binding the ALSA card to the HID vendor controls using the component
framework. The master's context lives in devres on the audio control
interface to manage its lifetime.

> diff --git a/sound/usb/mixer_topping.c b/sound/usb/mixer_topping.c
> new file mode 100644
> index 0000000000000..722f98f97d0bc
> --- /dev/null
> +++ b/sound/usb/mixer_topping.c
[ ... ]
> +static struct topping_master *topping_get_master(struct device *dev)
> +{
> +	return devres_find(dev, topping_master_release, NULL, NULL);
> +}
[ ... ]
> +static int topping_master_bind(struct device *dev)
> +{
> +	struct topping_master *tm = topping_get_master(dev);
> +
> +	if (WARN_ON(!tm))
> +		return -EINVAL;

[Severity: Medium]
Is it possible for this WARN_ON to trigger during a race condition with
device unbind?

If Thread A initiates USB unbind for the Audio Control interface,
devm_release_action() unlinks the devres node from the devres_head
before calling topping_master_teardown().

Thread B could then concurrently probe the HID interface and call
component_add(), acquiring component_mutex before Thread A does. Thread B
would attempt to bind the still-registered aggregate device and call
topping_master_bind().

When topping_get_master() searches the devres list via devres_find(), would
it return NULL because Thread A already unlinked the node, causing this
WARN_ON to trigger?

Since this WARN_ON is reachable via USB hotplug overlapping with deferred
probe, could it unexpectedly crash systems where panic_on_warn is enabled?

> +
> +	return component_bind_all(dev, tm->card);
> +}
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904162236.3212370-1-mikhail.v.gavrilov@gmail.com?part=2