Re: [PATCH v3 03/10] ASoC: renesas: fsi: Fix trigger stop ordering
Bui Duc Phuc <[email protected]> Fri, 5 Jun 2026 19:26:46 +0700
| Newsgroups | dev.linux.lists.sashiko,org.kernel.vger.linux-devicetree |
|---|---|
| Message-ID | <CAABR9nHfTtnUxLoq6rHJVmkjWjrAqqU1tawvAKQi-06_XXsKAw@mail.gmail.com> |
The points raised may be valid. However, this patch series is currently focused on fixing the system hang i= ssue. The other concerns will be addressed in a separate follow-up series. On Tue, May 12, 2026 at 5:44=E2=80=AFAM <[email protected]> wrote: > > Thank you for your contribution! Sashiko AI review found 4 potential issu= e(s) to consider: > - [High] TOCTOU race and lack of synchronization in stream stopping leads= to NULL pointer dereference. > - [High] Teardown asymmetry in `fsi_remove` leads to use-after-free and N= ULL pointer dereference. > - [High] Lockless read-modify-write on shared FSI port registers causes h= ardware corruption. > - [High] Lockless modifications to shared `clock->count` cause reference = count corruption. > -- > > commit 7ce4e3deeaefe8e811044e7b0472a2e9a2ae1d64 > Author: bui duc phuc <[email protected]> > > ASoC: renesas: fsi: Fix trigger stop ordering > > This commit reorders calls in the stop trigger to execute fsi_stream_stop= () > before fsi_hw_shutdown(). It ensures register accesses complete before th= e > clock is disabled to prevent a system hang. > > > diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c > > index 8cbd7acc26f49..94ab2e4908108 100644 > > --- a/sound/soc/renesas/fsi.c > > +++ b/sound/soc/renesas/fsi.c > > @@ -1586,9 +1586,9 @@ static int fsi_dai_trigger(struct snd_pcm_substre= am *substream, int cmd, > > ret =3D fsi_stream_transfer(io); > > break; > > case SNDRV_PCM_TRIGGER_STOP: > > Playback and capture substreams on the same FSI port share port-level > configuration registers like CKG1, CKG2, and OUT_SEL. > > Since the ALSA core serializes triggers at the substream level using > the self_group.lock, playback and capture triggers for the same DAI > can execute concurrently on different CPUs. > > Does fsi_hw_startup() perform lockless read-modify-write operations on th= ese > shared registers, and can this lack of exclusion lead to lost writes and > corrupted hardware state? > > > + fsi_stream_stop(fsi, io); > > During a stream stop, fsi_stream_stop() disables DMA via > dmaengine_terminate_all() and masks device interrupts, but it does not ap= pear > to wait for in-flight DMA callbacks or IRQ handlers to finish. > > Concurrently, an executing IRQ handler calling fsi_pio_transfer() will > temporarily take master->lock in fsi_stream_is_working(), drop it, and th= en > locklessly access io->substream->runtime inside fsi_pio_get_area(). > > Similarly, an asynchronous fsi_dma_complete() callback unconditionally > dereferences io->substream in fsi_pointer_update(). > > Since there is no dmaengine_terminate_sync() or synchronize_irq(), could > fsi_stream_quit() race with these callbacks and clear io->substream, > resulting in a NULL pointer dereference? > > The driver uses managed resources during fsi_probe(), meaning the IRQ han= dler > and ALSA component are unregistered after fsi_remove() returns. However, > fsi_remove() explicitly tears down the DMA streams via fsi_stream_remove(= ), > which calls dma_release_channel(io->chan) and sets io->chan to NULL. > > Because the ALSA component is still fully registered and active while > fsi_remove() completes, userspace can still trigger ALSA operations. > > If a STOP trigger occurs during this window, would calling > dmaengine_terminate_all(io->chan) here cause a NULL pointer dereference? > > > if (!ret) > > ret =3D fsi_hw_shutdown(fsi, dai->dev); > > The shared clock state for an FSI port is tracked using clock->count insi= de > fsi_priv. > > Since playback and capture triggers for the same port can execute > concurrently on different CPUs, do fsi_clk_enable() and fsi_clk_disable() > manually modify this counter without holding any lock? > > Could concurrent updates to clock->count corrupt the counter, potentially > leaving the peripheral clocks enabled permanently or disabling them while= a > stream is still active? > > > - fsi_stream_stop(fsi, io); > > fsi_stream_quit(fsi, io); > > break; > > } > > -- > Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260510084303.12= [email protected]?part=3D3