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:   Wed, 6 Dec 2017 11:54:27 -0800
From:   Stephen Boyd <>
To:     Bjorn Andersson <>,
        Jitendra Sharma <>
Cc:     Ohad Ben-Cohen <>,,,
Subject: Re: [PATCH] rpmsg: qcom_smd: Access APCS through mailbox framework

On 12/06/2017 11:02 AM, Bjorn Andersson wrote:
> On Wed 06 Dec 04:08 PST 2017, Jitendra Sharma wrote:
>> Hi Bjorn,
> Hi Jitendra,
>> On 11/16/2017 12:38 PM, Bjorn Andersson wrote:
> [..]
>>> @@ -365,7 +371,12 @@ static void qcom_smd_signal_channel(struct qcom_smd_channel *channel)
>>>   {
>>>   	struct qcom_smd_edge *edge = channel->edge;
>>> -	regmap_write(edge->ipc_regmap, edge->ipc_offset, BIT(edge->ipc_bit));
>>> +	if (edge->mbox_chan) {
>>> +		mbox_send_message(edge->mbox_chan, NULL);
>> mbox_send_message could fail. So return value should be checked
> qcom_apcs_ipc_send_data() can't fail, so the case when
> mbox_send_message() would fail is if more than MBOX_TX_QUEUE_LEN (20)
> callers that has managed to put their data in the queue but not yet
> execute msg_submit().
> As each bit in the APCS IPC register is modelled as it's own mailbox
> channel this error case would mean that as mbox_send_message() returns
> with an error there will soon be 20 callers entering
> qcom_apcs_ipc_send_data() and trigger this very bit.
> When this happens mbox_send_message() will print an error in the log, so
> there's no point in having the caller also print an error.
> When it comes to dealing with a failing call to mbox_send_message() we
> have already posted the message in the FIFO, so we have no way to abort
> the transmission, as such the only way to deal with this is to either
> retry or ignore the problem; and the mailbox queue will ensure that we
> retry 20 times.

Maybe you should wrap this up into a comment in the code? Then we don't
have to dig this out of the mail list archives to figure out why we
aren't checking for an error.

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

Powered by blists - more mailing lists