Re: [PATCH 0/4] ASoC: amd: fix IRQ handler races in AMD SoundWire drivers

[Mukunda,Vijendar]

On 07/11/26 23:22, Vijendar Mukunda wrote:
> These four patches fix two related race conditions in the AMD SoundWire
> IRQ handlers for the PS (ACP63) and SOF platforms.
>
> Patches 1 and 2 guard against a NULL dereference in the ACP external IRQ
> handler.  The handler is registered before sdw_amd_probe() assigns
> adata->sdw, so a stray interrupt in the probe window, or one that fires
> after sdw_amd_exit() frees the context, can reach the adata->sdw->pdev[i]
> dereference with adata->sdw still NULL.
>
> Patches 3 and 4 guard schedule_work() calls with the interrupt_enabled
> flag so that an in-flight IRQ arriving while the SoundWire manager is
> being torn down does not queue new work after amd_disable_sdw_interrupts()
> has cleared the flag.
>
> NOTE: Patches 3 and 4 depend on the following patch which introduces the
> interrupt_enabled field in the AMD SoundWire manager:
>
>   https://lore.kernel.org/linux-sound/20261107154659.3358223-18-Vijendar.Mukunda@xxxxxxx/
>
> Until that patch is merged, patches 3 and 4 should not be picked up
> independently.
Hi Mark, Vinod,
 
The following two series have a build and correctness dependency on
each other:
 
SoundWire fix series (25 patches):
https://lore.kernel.org/linux-sound/20261107154659.3358223-1-Vijendar.Mukunda@xxxxxxx/
 
Companion ASoC series (4 patches):
https://lore.kernel.org/alsa-devel/20261107175339.3547918-2-Vijendar.Mukunda@xxxxxxx/
 
ASoC patches 1/4 and 2/4 reference the interrupt_enabled member of
struct amd_sdw_manager introduced by SoundWire patch 17/25, so the
ASoC patches will not build without the SoundWire series. SoundWire
patch 18/25 delays *sdw_ctx publication until after startup succeeds,
opening a probe-window race in acp63_irq_handler() and
acp_irq_handler() that ASoC patches 3/4 and 4/4 close with adata->sdw
NULL checks.
 
Because the two series are split across trees, the Sashiko AI review
tool sees each series in isolation and raises the cross-tree dependency
as unresolved races:
 
https://sashiko.dev/#/patchset/20261107154659.3358223-1-Vijendar.Mukunda%40amd.com
https://sashiko.dev/#/patchset/20261107175339.3547918-1-Vijendar.Mukunda%40amd.com
 
When both series were combined and run through Sashiko as a single
patch set, none of these cross-dependency issues were reported,
confirming that the concerns are an artifact of the split rather than
real bugs. Reposting as a single combined series would give Sashiko
the full context and make the review cycle easier. Please let us know
if that is the preferred approach.
 
Thanks,
Vijendar



> Vijendar Mukunda (4):
>   ASoC: amd: ps: guard adata->sdw dereferences with NULL check in IRQ
>     handler
>   ASoC: SOF: amd: guard adata->sdw dereferences with NULL check in IRQ
>     handler
>   ASoC: SOF: amd: guard SDW IRQ work scheduling with interrupt_enabled
>     flag
>   ASoC: amd: ps: guard SDW IRQ work scheduling with interrupt_enabled
>     flag
>
>  sound/soc/amd/ps/pci-ps.c | 32 ++++++++++++++++++++------------
>  sound/soc/sof/amd/acp.c   | 32 ++++++++++++++++++++------------
>  2 files changed, 40 insertions(+), 24 deletions(-)
>
> --
> 2.53.0