On Mon, 30 May 2022 11:36:39 +0200, Charles Keepax wrote:
On Mon, May 30, 2022 at 11:18:43AM +0200, Takashi Iwai wrote:
On Mon, 30 May 2022 11:08:46 +0200, Charles Keepax wrote:
On Fri, May 27, 2022 at 06:13:38PM +0200, Takashi Iwai wrote:
On Wed, 25 May 2022 15:16:21 +0200, Vitaly Rodionov wrote: The idea to add / delete controls by the control element change doesn't sound good; as already mentioned in my reply to the previous patch set, the change of the control elements can be triggered too easily by any normal users who have the access to the sound devices. It means thousands of additions and removals per second could be attacked by any user.
This I am a little less sure how we handle. I mean arn't there already a few ways to do this? Both the existing ASoC wm_adsp stuff, and the topology stuff (used on all new Intel platforms, so very widely deployed) let you create controls by loading a firmware file. Also within ALSA itself can't user-space create user ALSA controls? Is there some rate limiting on that? How is this issue tackled there?
The creation of kctls via firmware loading would be OK, as the code path can't be triggered so frequently. Is it the case for this patch set? There was too little information about the implementation (and more importantly, how to use the controls), so it's hard to judge...
Yeah that should be what is happening here. Although it looks like this code might be removing all the controls if the firmware is unloaded. I will discuss that with the guys, we normal just disable the controls on the wm_adsp stuff.
OK, that sounds good. Basically my concern came up from the code snippet doing asynchronous addition/removal via work. This showed some yellow signal, as such a pattern doesn't appear in the normal implementation. If this is (still) really necessary, it has to be clarified as an exception.
thanks,
Takashi