Re: [RFC PATCH v5 2/2] ALSA: usb-audio: bind the Topping M62's vendor controls
From: sashiko-bot@kernel.org
Date: 2026-09-04 16:43:21
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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