[PATCH v3] ALSA: control: Add memory consumption limit to user controls

[Takashi Iwai]

On Sat, 10 Apr 2021 10:22:18 +0200,
Takashi Sakamoto wrote:
> 
> On Fri, Apr 09, 2021 at 04:18:00PM +0200, Takashi Iwai wrote:
> > On Fri, 09 Apr 2021 15:34:14 +0200,
> > Jaroslav Kysela wrote:
> > > 
> > > Dne 09. 04. 21 v 12:59 Takashi Iwai napsal(a):
> > > 
> > > >> 5. add any mechanism to bind lifetime of user-defined element set to user
> > > >>    process
> > > >>
> > > >> At present, the lifetime of user-defined element set is bound to card
> > > >> itself. However, it's convenient to user processes to bind the lifetime
> > > >> to process itself. I add any mechanism for it.
> > > >>
> > > >> For recent years I've made some patches in house but never arrive at the
> > > >> best one. In the patches, I utilize access flags but in general the
> > > >> maintenance of lifetime is not easy issue. I tackle again in this time.
> > > > 
> > > > It sounds interesting, but I don't know how easily you can manage it.
> > > > The driver doesn't care much about the user process lifetime, but
> > > > mostly concentrate on the file handle...
> > > 
> > > It should be easy to trace which process created the user element and
> > > automatically remove this element when the process close the file descriptor.
> > > Something like 'bind lifetime of the control to the active control file
> > > descriptor'.
> > 
> > If it's tied only with the file handle, it's easy.  But I thought this
> > is about the process?
> 
> The 'lifetime' relates any operations from userspace relevant to
> element. In the point, it's not so easy. It's better to see the list of
> ioctl request to ALSA control character device, guys.

I'm lost.  What makes so difficult if the element is tied with the
file descriptor?  You'd nuke the corresponding element at
snd_ctl_release(), and it should be enough.

If it's not tied with the file descriptor, it's indeed difficult, but
it has nothing to do with the number of ioctl implementations.


Takashi