All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sreeraj S Kurup" <sreekuttan2156239@gmail.com>
Cc: linux-sound@vger.kernel.org
Subject: Re: [PATCH] ALSA: control: Synchronize LED mode accesses
Date: Fri, 06 Nov 2026 18:16:28 +0000	[thread overview]
Message-ID: <sashiko-outbox-202004@kernel.org> (raw)
In-Reply-To: <20261106180812.5097-1-sreekuttan2156239@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] ALSA: control: missing Fixes trailer for led->mode data race fix
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [Medium] ALSA: control_led: data race in snd_ctl_led_reset() [1]
--

commit 2868f72034945ef393b8a3a1a9c6b9d772455395
Author: Sreeraj S Kurup <sreekuttan2156239@gmail.com>

> ALSA: control: Synchronize LED mode accesses
>
> mode_store() updates led->mode while holding
> snd_ctl_led_mutex.
>
> However, snd_ctl_led_set_state() and mode_show() read this
> field without holding the same mutex.
>
> This can cause a data race when userspace changes the mode
> while another path reads it.
>
> Read the mode under snd_ctl_led_mutex in
> snd_ctl_led_set_state() and use the local value after
> releasing the mutex.
>
> Also protect the mode read in mode_show() with the mutex.
>
> Signed-off-by: Sreeraj S Kurup <sreekuttan2156239@gmail.com>

[Severity: Low]
Since this fixes the unlocked reads of led->mode introduced when sysfs
support was added, should this include a Fixes tag?

  Fixes: cb17fe0045aa ("ALSA: control - add sysfs support to the LED trigger module")

> diff --git a/sound/core/control_led.c b/sound/core/control_led.c
> index 501387287ae69..044430b2f1a22 100644
> --- a/sound/core/control_led.c
> +++ b/sound/core/control_led.c

[ ... ]

> @@ -382,6 +384,8 @@ static ssize_t mode_show(struct device *dev,
>  	struct snd_ctl_led *led = container_of(dev, struct snd_ctl_led, dev);
>  	const char *str = NULL;
>  
> +	guard(mutex)(&snd_ctl_led_mutex);

[Severity: Medium]
This problem wasn't introduced by this patch, but can snd_ctl_led_reset()
and snd_ctl_led_set_id() race on vd->access [1]?

Concurrent sysfs writes to the reset and attach or detach attributes
modify vd->access under different locks: snd_ctl_led_reset() holds only
snd_ctl_led_mutex, whereas snd_ctl_led_set_id() holds only
card->controls_rwsem.

CPU0                                  CPU1
snd_ctl_led_reset()                   snd_ctl_led_set_id()
  scoped_guard(mutex,
               &snd_ctl_led_mutex)
                                        guard(rwsem_write)(
                                          &card->controls_rwsem)
                                        new_access = vd->access & ~mask;
    vd->access &= ~group_to_access();
                                        vd->access = new_access;
                                          <-- overwrites reset

The lost update leaves the control's LED access flags out of sync with the
LED group's control list.

[1] https://sashiko.dev/#/bug/linux-55c9a300-c6f3-4df1-9060-c4bb4df43d19

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106180812.5097-1-sreekuttan2156239@gmail.com?part=1

  reply	other threads:[~2026-11-06 18:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 18:08 [PATCH] ALSA: control: Synchronize LED mode accesses Sreeraj S Kurup
2026-11-06 18:16 ` sashiko-bot [this message]
2026-11-06 18:39 ` [PATCH v2] " Sreeraj S Kurup
2026-11-07  9:09   ` Takashi Iwai
2026-11-07 11:55     ` [PATCH] " Sreeraj S Kurup
2026-11-07 11:59     ` [PATCH v2] " Sreeraj S Kurup
2026-11-07 12:12     ` Sreeraj S Kurup
2026-11-07 13:59       ` Takashi Iwai
2026-11-08  9:50         ` Sreeraj S Kurup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-202004@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sreekuttan2156239@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.