Re: [PATCH 08/28] ALSA: control: Add kcontrol callbacks for lock/unlock

[Takashi Iwai <tiwai@suse.de>]

On Sat, 03 Oct 2026 08:39:16 +0200,
Takashi Iwai wrote:
> 
> On Sat, 03 Oct 2026 03:34:07 +0200,
> James Calligeros wrote:
> > 
> > On Tuesday, 29 September 2026 7:52:59 pm Australian Eastern Standard Time 
> > Takashi Iwai wrote:
> > > On Sun, 20 Sep 2026 06:53:47 +0200,
> > > 
> > > James Calligeros wrote:
> > > > From: Hector Martin <marcan@marcan.st>
> > > > 
> > > > This allows drivers to implement policy around locking/unlocking
> > > > controls, such as enforcing that a group of controls may only be locked
> > > > by the same process/file, and taking actions when the controls
> > > > lock/unlock (such as granting special access on lock and resetting
> > > > values on unlock).
> > > > 
> > > > This is, in particular, useful to implement volume safety controls, such
> > > > that only a particular process (that locks controls and completes a
> > > > handshake) may increase volumes above a given safe limit. It also allows
> > > > the volume to be automatically lowered if that process dies (which will
> > > > trigger an implicit unlock).
> > > > 
> > > > Signed-off-by: Hector Martin <marcan@marcan.st>
> > > > Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> > > 
> > > This doesn't sound like a good approach to me, and this looks rather
> > > irrelevant with the purpose of the series.
> > 
> > I'm not sure what you mean by it being irrelevant. A significant portion
> > of the machine driver is dedicated to implementing safety interlocks based
> > on the functionality added via this patch. It would be impossible to prevent
> > badly-behaving users{,pace} from defeating the safety guarantees made by
> > speakersafetyd (and thus permanently damaging the machine) without giving
> > speakersafetd exclusive ownership over the safety interlock kcontrol.
> 
> Improving the lock/unlock itself can be an interesting idea (but we
> should do in a different way instead of blindly extending each kernel
> control ops).  OTOH, the whole implementation of the driver and the
> feature depending on that stuff sounds rather fragile.

Also, if you want a locking by user-space, how about to simply provide
a boolean control element for locking, instead of extending the whole
API and infrastructure?  The control can be taken exclusively for a
process, and the driver just blocks the operations from others while
the flag is set via that kcontrol.


Takashi