Re: [PATCH 1/4] ALSA: compress: fix buffer leak on repeated SET_PARAMS

["Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>]

On 08/10/2026 09:25, Péter Ujfalusi wrote:
>>>> I would block calling snd_compr_allocate_buffer() for subsequent
>>>> set_params, it should not be allowed.
>>>
>>> OK, let me see how it should be done. I'm not sure of changing other
>>> params are permitted either, but imagine:
>>
>> I would split it up for next_track and open, so that we have clear
>> flows.
>>
>>> the application calls set_params first then after some deliberation and
>>> before starting it reconsiders and wants to have bigger/smaller buffer.
>>> I know, they rarely do, but if such application assumes that the second
>>> buffer setup is valid, while we kept the initial one, things might break?
>>
>> Hmmm, do we really want that. they can tear down and reopen in that
>> case?
>>
>> If we split as above, in next_track case we can apply codec params while
>> ignoring buffer.. wdyt
> 
> What if we just refuse consequent set_params in OPEN state?
> That does not make much sense and can collapse patch 1 and 2 into one.
tried several other ways on this (patch 2 included) and at the end I
have ended up with the exact same patches.

Two separate issues and the two patch covers the points well.

The set_params in OPEN state is sticking out, but I think that allowing
it to re-allocate memory is the right thing:
this can only happen if the stream->ops->set_params(stream, params);
fails and in that case user space might want to try different memory layout.

I would leave the series unchanged.

-- 
Péter