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]

Message-ID: <20190131011649.GA27190@builder>
Date:   Wed, 30 Jan 2019 17:16:49 -0800
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Srinivas Kandagatla <srinivas.kandagatla@...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 Thu 15 Nov 10:49 PST 2018, Srinivas Kandagatla wrote:

> APR communication with DSP is not atomic in nature.
> Its request-response type. Trying to pretend that these are atomic
> and invoking apr client callbacks directly under atomic/irq context has
> endless issues with soundcard. It makes more sense to convert these
> to nonatomic calls. This also coverts all the dais to be nonatomic.
> 

Hi Srinivas,

Sorry for not looking at this before.

Are you sure that you're meeting the latency requirements of low-latency
audio with this change?

[..]
> @@ -303,6 +363,10 @@ static int apr_remove_device(struct device *dev, void *null)
>  
>  static void apr_remove(struct rpmsg_device *rpdev)
>  {
> +	struct apr *apr = dev_get_drvdata(&rpdev->dev);
> +
> +	flush_workqueue(apr->rxwq);
> +	destroy_workqueue(apr->rxwq);

The devices may still be communicating until you remove them on the next
line, wouldn't it make more sense to destroy the work queue after
removing the APR devices?

>  	device_for_each_child(&rpdev->dev, NULL, apr_remove_device);
>  }

Regards,
Bjorn