linux-kernel - Re: [PATCH] qcom: apr: Make apr callbacks in non-atomic context

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 31 Jan 2019 17:33:11 +0000
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     andy.gross@...aro.org, david.brown@...aro.org,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-kernel@...r.kernel.org, bgoswami@...eaurora.org,
        rohitkr@...eaurora.org
Subject: Re: [PATCH] qcom: apr: Make apr callbacks in non-atomic context

On 31/01/2019 16:05, Bjorn Andersson wrote:
> Sure, but we want the design to allow for that still, either in future
> upstream or by additional downstream code.
> 
Yes, I agree, I don't have solution for this ATM.
It will be interesting to see how Intel handles this kind of usecase on 
there DSP.

The whole issue is the APR messaging is not really atomic in nature, it 
is basically request->response but the fact in existing code is that 
smd/glink callbacks run in interrupt context.

Trying to pretend that APR is atomic in nature is problem with audio.

As audio (dai-links) can be marked as atomic or non-atomic depending on 
which bus it links with, for example when it has to work with other 
buses like slimbus, soundwire, i2c whose transactions can sleep we mark 
the audio dai-link as non-atomic which means that the functions can sleep.
In the above case, invoking any audio functions as part of the rpmsg 
callback is an issue.

The only solution I found to address this is handle the callbacks in 
workqueue.

>> Also it depends on definition of "latency", is the latency referring to
>> "filling the data" or "latency between DSP command and response".
>>
> I'm referring to the latency between the message from the DSP until we
> give it a new buffer.
> 
>> For former case as long as we have more samples in our ring buffer there
>> should be no latency in filling the data.
>> For later case it should not really matter as long as former case is taken
>> care off.
>>
>> Low latency audio involves smaller sample sizes and no or minimal
>> preprocessing in DSP so am guessing that we should be okay with responses in
>> workqueue as long as we have good size ring buffer.
>>
> Relying on more buffered data will increase the latency of the audio,
> preventing you from doing really low-latency things.
My bad!.. Yes, in low latency case we would have very less buffers!

srini