linux-kernel - ASoC: SOF: Race condition in ipc.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAES_P+_aC4cHMB3Tn0pz13_gKCpXs=efeae2JBvEPOK5zidYnA@mail.gmail.com>
Date:   Mon, 20 Jun 2022 19:46:23 -0700
From:   noman pouigt <variksla@...il.com>
To:     Mark Brown <broonie@...nel.org>, liam.r.girdwood@...ux.intel.com
Cc:     linux-kernel@...r.kernel.org, yangyingliang@...wei.com,
        alsa-devel@...a-project.org, sound-open-firmware@...a-project.org,
        yung-chuan.liao@...ux.intel.com, ranjani.sridharan@...ux.intel.com,
        peter.ujfalusi@...ux.intel.com,
        pierre-louis.bossart@...ux.intel.com, rander.wang@...el.com
Subject: ASoC: SOF: Race condition in ipc.c

Folks,

I have borrowed part of SOF architecture for my own DSP
framework development as the memory on the DSP is
extremely small and wouldn't be able to support SOF.

Currently I am running into a race condition as below:

CPU                                            DSP
PCM_TRIGGER_START
sof_ipc_send_msg ---->

                                      <------Immediate ACK
ipc3_wait_tx_done
(wait_event_timeout)
                                      <------ POSITION update

snd_pcm_period_elapsed

As you can see TRIGGER_START didn't even finish
and waiting for it to complete in ipc3_wait_tx_done
function. However, before it could complete the position
interrupt was issued which results in calling period_elapsed
function.

In order to fix this I assume below is called in SOF framework:
schedule_work(&spcm->stream[substream->stream].period_elapsed_work);

How is this design working? If the interrupt is coming too fast
from the DSP than the associated function with this schedule_work
will not get called as the scheduler will not get time to schedule the
workqueue and elapsed function will not be called thereby not increasing
the hw_ptr. How is the flow control for data transfer achieved?

I am facing the above problem in my design.

I am wondering if I can simply add one more IPC command(don't call
wait_event_interruptible for this) after TRIGGER_START to start the
streaming.This way schedule_work for updating period_elapsed function
can be avoided and it can be called in an interrupt context.

Thanks,
Variksla