linux-kernel - Re: [PATCH 1/3] soc: qcom: Introduce Protection Domain Restart helpers

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

Date:   Wed, 20 Nov 2019 12:12:54 +0000
From:   Sibi Sankar <sibis@...eaurora.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     srinivas.kandagatla@...aro.org, robh+dt@...nel.org,
        tsoni@...eaurora.org, agross@...nel.org, mark.rutland@....com,
        linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        rnayak@...eaurora.org, linux-remoteproc-owner@...r.kernel.org
Subject: Re: [PATCH 1/3] soc: qcom: Introduce Protection Domain Restart
 helpers

On 2019-11-20 04:47, Bjorn Andersson wrote:
> On Tue 19 Nov 02:18 PST 2019, sibis@...eaurora.org wrote:
> 
>> Hey Bjorn,
>> Thanks for taking the time to
>> review the series :)
>> 
>> On 2019-11-19 12:10, Bjorn Andersson wrote:
>> > On Mon 18 Nov 06:27 PST 2019, Sibi Sankar wrote:
>> > > diff --git a/drivers/soc/qcom/pdr_interface.c
>> > > b/drivers/soc/qcom/pdr_interface.c
>> > [..]
>> > > +static void pdr_indack_work(struct work_struct *work)
>> > > +{
>> > > +	struct pdr_handle *pdr = container_of(work, struct pdr_handle,
>> > > +					      indack_work);
>> > > +	struct pdr_list_node *ind, *tmp;
>> > > +	struct pdr_service *pds;
>> > > +
>> > > +	list_for_each_entry_safe(ind, tmp, &pdr->indack_list, node) {
>> > > +		pds = ind->pds;
>> > > +		pdr_send_indack_msg(pdr, pds, ind->transaction_id);
>> >
>> > So when we et a ind_cb with the new status, we need to send an ack
>> > request, which will result in a response, just to confirm that we got
>> > the event?
>> >
>> > Seems like we should fix the qmi code to make it possible to send a
>> > request from the indication handler and then we could simply ignore the
>> 
>> yeah maybe having a provision to send custom requests back on
>> indication would be the way to go. Not all indication need to be
>> services with requests.
>> 
> 
> Let's put this on the todo list.
> 
>> > response. Or do we need to not pdr->status() until we get the response
>> > for some reason?
>> 
>> adsp waits on the ack response for a fixed duration and seems to throw
>> a fatal err is the ack is not serviced. Hence holding back pd->status
>> till we service the ack here.
>> 
> 
> You mean to ensure that someone sleeping in pd->status() doesn't delay
> that until its too late?

yes

> 
> [..]
>> > > +int pdr_handle_init(struct pdr_handle *pdr,
>> > > +		    int (*status)(struct pdr_handle *pdr,
>> > > +				  struct pdr_service *pds))
>> > > +{
>> > [..]
>> > > +	pdr->servreg_wq = create_singlethread_workqueue("pdr_servreg_wq");
>> > > +	if (!pdr->servreg_wq)
>> > > +		return -ENOMEM;
>> > > +
>> > > +	pdr->indack_wq = alloc_ordered_workqueue("pdr_indack_wq",
>> > > WQ_HIGHPRI);
>> >
>> > The two workqueues means that we should be able to call pdr->status()
>> > rom two concurrent contexts, I don't think our clients will expect that.
>> >
>> 
>> would creating another ordered wq to relay all the pd->status make
>> sense?
>> 
> 
> I would prefer less work queues ;) But I presume you split out the
> indack_wq in order to improve the likelihood of meeting the latency
> requirements of the remote side.
> 
> Perhaps just wrap the status() calls with a status-mutex and then 
> remove
> that by reworking the QMI interface to allow us to remove the indack
> work?

okay will fix it in the next
re-spin.

> 
> Regards,
> Bjorn

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.