* [PATCH 1/3] ASoC: Intel: avs: Unprepare a stream when recovery occurs
2026-10-15 19:02 [PATCH 0/3] ASoC: Intel: avs: Fix for recovery procedure and new size-checks Cezary Rojewski
@ 2026-10-15 19:02 ` Cezary Rojewski
2026-10-15 19:25 ` Amadeusz Sławiński
2026-10-15 19:02 ` [PATCH 2/3] ASoC: Intel: avs: Verify sizes of configs coming from topology Cezary Rojewski
` (2 subsequent siblings)
3 siblings, 1 reply; 7+ messages in thread
From: Cezary Rojewski @ 2026-10-15 19:02 UTC (permalink / raw)
To: broonie, linux-sound; +Cc: tiwai, perex, amade, linux-kernel, Cezary Rojewski
Recovery on alsa-lib side is handled with either:
1) snd_pcm_prepare(state=XRUN)
2) snd_pcm_drop/drain() -> snd_pcm_prepare(state=SETUP)
before starting the PCM anew. Relying solely on state=XRUN leaves 2)
unaccounted for. sound/core/pcm_native.c ensures correctness of the
state machine so plain state!=PREPARED check suffices.
This is the BE equivalent of job done previously for FE side only with
commit cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN
occurs") and its follow up titled: ("ASoC: Intel: avs: Reset the stream
unless it is already prepared").
Link: https://lore.kernel.org/linux-sound/20261010103753.16969-1-stiraspo@gmail.com/T/
Fixes: d070002a20fc ("ASoC: Intel: avs: HDA PCM BE operations")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
---
sound/soc/intel/avs/pcm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/intel/avs/pcm.c b/sound/soc/intel/avs/pcm.c
index 3cf455e8b879..a0a0d645ea33 100644
--- a/sound/soc/intel/avs/pcm.c
+++ b/sound/soc/intel/avs/pcm.c
@@ -461,6 +461,8 @@ static int avs_dai_hda_be_prepare(struct snd_pcm_substream *substream, struct sn
link_stream = data->link_stream;
p = &be->dpcm[substream->stream].hw_params;
+ if (substream->runtime->state != SNDRV_PCM_STATE_PREPARED)
+ link_stream->link_prepared = false;
if (link_stream->link_prepared)
return 0;
--
2.34.1
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 1/3] ASoC: Intel: avs: Unprepare a stream when recovery occurs
2026-10-15 19:02 ` [PATCH 1/3] ASoC: Intel: avs: Unprepare a stream when recovery occurs Cezary Rojewski
@ 2026-10-15 19:25 ` Amadeusz Sławiński
2026-10-16 7:51 ` Cezary Rojewski
0 siblings, 1 reply; 7+ messages in thread
From: Amadeusz Sławiński @ 2026-10-15 19:25 UTC (permalink / raw)
To: Cezary Rojewski; +Cc: broonie, linux-sound, tiwai, perex, linux-kernel
On Thu, 15 Oct 2026 21:02:38 +0200
Cezary Rojewski <cezary.rojewski@intel.com> wrote:
> Recovery on alsa-lib side is handled with either:
> 1) snd_pcm_prepare(state=XRUN)
> 2) snd_pcm_drop/drain() -> snd_pcm_prepare(state=SETUP)
>
> before starting the PCM anew. Relying solely on state=XRUN leaves 2)
> unaccounted for. sound/core/pcm_native.c ensures correctness of the
> state machine so plain state!=PREPARED check suffices.
>
> This is the BE equivalent of job done previously for FE side only with
> commit cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN
> occurs") and its follow up titled: ("ASoC: Intel: avs: Reset the stream
> unless it is already prepared").
>
> Link: https://lore.kernel.org/linux-sound/20261010103753.16969-1-stiraspo@gmail.com/T/
> Fixes: d070002a20fc ("ASoC: Intel: avs: HDA PCM BE operations")
> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
> ---
> sound/soc/intel/avs/pcm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/sound/soc/intel/avs/pcm.c b/sound/soc/intel/avs/pcm.c
> index 3cf455e8b879..a0a0d645ea33 100644
> --- a/sound/soc/intel/avs/pcm.c
> +++ b/sound/soc/intel/avs/pcm.c
> @@ -461,6 +461,8 @@ static int avs_dai_hda_be_prepare(struct snd_pcm_substream *substream, struct sn
> link_stream = data->link_stream;
> p = &be->dpcm[substream->stream].hw_params;
>
> + if (substream->runtime->state != SNDRV_PCM_STATE_PREPARED)
> + link_stream->link_prepared = false;
> if (link_stream->link_prepared)
> return 0;
>
It's bit late, so I can be wrong, but if you are going to execute whole
function in most cases anyway, is link_prepared even needed? Why not just:
if (substream->runtime->state == SNDRV_PCM_STATE_PREPARED)
return 0;
and remove link_prepared entirely?
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 1/3] ASoC: Intel: avs: Unprepare a stream when recovery occurs
2026-10-15 19:25 ` Amadeusz Sławiński
@ 2026-10-16 7:51 ` Cezary Rojewski
0 siblings, 0 replies; 7+ messages in thread
From: Cezary Rojewski @ 2026-10-16 7:51 UTC (permalink / raw)
To: Amadeusz Sławiński
Cc: broonie, linux-sound, tiwai, perex, linux-kernel
On 10/15/2026 9:25 PM, Amadeusz Sławiński wrote:
> On Thu, 15 Oct 2026 21:02:38 +0200
> Cezary Rojewski <cezary.rojewski@intel.com> wrote:
>
>> Recovery on alsa-lib side is handled with either:
>> 1) snd_pcm_prepare(state=XRUN)
>> 2) snd_pcm_drop/drain() -> snd_pcm_prepare(state=SETUP)
>>
>> before starting the PCM anew. Relying solely on state=XRUN leaves 2)
>> unaccounted for. sound/core/pcm_native.c ensures correctness of the
>> state machine so plain state!=PREPARED check suffices.
>>
>> This is the BE equivalent of job done previously for FE side only with
>> commit cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN
>> occurs") and its follow up titled: ("ASoC: Intel: avs: Reset the stream
>> unless it is already prepared").
>>
>> Link: https://lore.kernel.org/linux-sound/20261010103753.16969-1-stiraspo@gmail.com/T/
>> Fixes: d070002a20fc ("ASoC: Intel: avs: HDA PCM BE operations")
>> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
>> ---
>> sound/soc/intel/avs/pcm.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/sound/soc/intel/avs/pcm.c b/sound/soc/intel/avs/pcm.c
>> index 3cf455e8b879..a0a0d645ea33 100644
>> --- a/sound/soc/intel/avs/pcm.c
>> +++ b/sound/soc/intel/avs/pcm.c
>> @@ -461,6 +461,8 @@ static int avs_dai_hda_be_prepare(struct snd_pcm_substream *substream, struct sn
>> link_stream = data->link_stream;
>> p = &be->dpcm[substream->stream].hw_params;
>>
>> + if (substream->runtime->state != SNDRV_PCM_STATE_PREPARED)
>> + link_stream->link_prepared = false;
>> if (link_stream->link_prepared)
>> return 0;
>>
>
> It's bit late, so I can be wrong, but if you are going to execute whole
> function in most cases anyway, is link_prepared even needed? Why not just:
> if (substream->runtime->state == SNDRV_PCM_STATE_PREPARED)
> return 0;
> and remove link_prepared entirely?
I do agree that something is amiss here. As mentioned during a parallel
review [1] with these checks added, I doubt ->prepared and
->link_prepared are needed.
All of these is a separate investigation though and I've decided to go
with what has been touched, at least for now.
[1]:
https://lore.kernel.org/linux-sound/179182811090.390394.9718829794059346472.b4-ty@b4/T/#m72e50a5e55c45570926a88ebd260343e11847eaa
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 2/3] ASoC: Intel: avs: Verify sizes of configs coming from topology
2026-10-15 19:02 [PATCH 0/3] ASoC: Intel: avs: Fix for recovery procedure and new size-checks Cezary Rojewski
2026-10-15 19:02 ` [PATCH 1/3] ASoC: Intel: avs: Unprepare a stream when recovery occurs Cezary Rojewski
@ 2026-10-15 19:02 ` Cezary Rojewski
2026-10-15 19:02 ` [PATCH 3/3] ASoC: Intel: avs: Prevent module info underflow Cezary Rojewski
2026-10-15 19:14 ` [PATCH 0/3] ASoC: Intel: avs: Fix for recovery procedure and new size-checks Mark Brown
3 siblings, 0 replies; 7+ messages in thread
From: Cezary Rojewski @ 2026-10-15 19:02 UTC (permalink / raw)
To: broonie, linux-sound; +Cc: tiwai, perex, amade, linux-kernel, Cezary Rojewski
Before operating on the init_config or NHLT-blob entries check whether
their sizes are within bounds of the block being parsed.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
---
sound/soc/intel/avs/topology.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/sound/soc/intel/avs/topology.c b/sound/soc/intel/avs/topology.c
index 1085090d5a9c..e81401bb6dbd 100644
--- a/sound/soc/intel/avs/topology.c
+++ b/sound/soc/intel/avs/topology.c
@@ -1720,6 +1720,10 @@ static int avs_tplg_parse_initial_configs(struct snd_soc_component *comp,
AVS_TKN_INIT_CONFIG_ID_U32,
mod_init_config_parsers,
ARRAY_SIZE(mod_init_config_parsers));
+ if (ret)
+ return ret;
+ if (config->length > block_size)
+ return -EINVAL;
block_size -= esize;
@@ -1790,6 +1794,8 @@ static int avs_tplg_parse_nhlt_configs(struct snd_soc_component *comp,
/* With tuples parsed, the blob shall be allocated. */
if (!config->blob)
return -EINVAL;
+ if (config->blob->capabilities_size > block_size)
+ return -EINVAL;
/* Consume the raw data and move to the next entry. */
memcpy(config->blob->capabilities, (u8 *)tuples + esize,
--
2.34.1
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 3/3] ASoC: Intel: avs: Prevent module info underflow
2026-10-15 19:02 [PATCH 0/3] ASoC: Intel: avs: Fix for recovery procedure and new size-checks Cezary Rojewski
2026-10-15 19:02 ` [PATCH 1/3] ASoC: Intel: avs: Unprepare a stream when recovery occurs Cezary Rojewski
2026-10-15 19:02 ` [PATCH 2/3] ASoC: Intel: avs: Verify sizes of configs coming from topology Cezary Rojewski
@ 2026-10-15 19:02 ` Cezary Rojewski
2026-10-15 19:14 ` [PATCH 0/3] ASoC: Intel: avs: Fix for recovery procedure and new size-checks Mark Brown
3 siblings, 0 replies; 7+ messages in thread
From: Cezary Rojewski @ 2026-10-15 19:02 UTC (permalink / raw)
To: broonie, linux-sound; +Cc: tiwai, perex, amade, linux-kernel, Cezary Rojewski
Typically modules information is first initialized when loading the base
AudioDSP base firmware and then expanded when loadable DSP modules are
requested by platform-components, see avs_component_load_libraries().
While theoretically not possible in a production scenario, there is no
reason to continue the IDAs preparation if an event caused the newly
obtained module information to be smaller or equal than the existing
information.
Fixes: c1a427e8da93 ("ASoC: Intel: avs: Firmware resources management utilities")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
---
sound/soc/intel/avs/utils.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/sound/soc/intel/avs/utils.c b/sound/soc/intel/avs/utils.c
index ea14ec173855..f19a62e7e8b5 100644
--- a/sound/soc/intel/avs/utils.c
+++ b/sound/soc/intel/avs/utils.c
@@ -116,9 +116,11 @@ avs_module_ida_alloc(struct avs_dev *adev, struct avs_mods_info *newinfo, bool p
int i;
if (!purge && oldinfo) {
- if (oldinfo->count >= newinfo->count)
- dev_warn(adev->dev, "refreshing %d modules info with %d\n",
+ if (oldinfo->count >= newinfo->count) {
+ dev_warn(adev->dev, "modules info underflow, old: %d, new: %d\n",
oldinfo->count, newinfo->count);
+ return -EPROTO;
+ }
tocopy_count = oldinfo->count;
}
--
2.34.1
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 0/3] ASoC: Intel: avs: Fix for recovery procedure and new size-checks
2026-10-15 19:02 [PATCH 0/3] ASoC: Intel: avs: Fix for recovery procedure and new size-checks Cezary Rojewski
` (2 preceding siblings ...)
2026-10-15 19:02 ` [PATCH 3/3] ASoC: Intel: avs: Prevent module info underflow Cezary Rojewski
@ 2026-10-15 19:14 ` Mark Brown
3 siblings, 0 replies; 7+ messages in thread
From: Mark Brown @ 2026-10-15 19:14 UTC (permalink / raw)
To: linux-sound, Cezary Rojewski; +Cc: tiwai, perex, amade, linux-kernel
On Thu, 15 Oct 2026 21:02:37 +0200, Cezary Rojewski wrote:
> ASoC: Intel: avs: Fix for recovery procedure and new size-checks
>
> The first change addresses XRUN recovery for HDA-Link i.e.: BackEnd
> side of a HDAudio stream.
>
> It is the BE side equivalent of job done previously for FE side only
> with commit cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when
> XRUN occurs") and its follow up titled: ("ASoC: Intel: avs: Reset the
> stream unless it is already prepared") [1].
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.4
Thanks!
[1/3] ASoC: Intel: avs: Unprepare a stream when recovery occurs
https://git.kernel.org/broonie/sound/c/85bc213f96ac
[2/3] ASoC: Intel: avs: Verify sizes of configs coming from topology
https://git.kernel.org/broonie/sound/c/6e6aedb1f876
[3/3] ASoC: Intel: avs: Prevent module info underflow
https://git.kernel.org/broonie/sound/c/05c2975b4267
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply [flat|nested] 7+ messages in thread