linux-kernel - Re: [PATCH v2 14/16] net: qrtr: Add MHI transport layer

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 for Android: free password hash cracker in your pocket

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

Message-ID: <53018abf-4bc9-1ddb-0be5-a9a3b9871a33@codeaurora.org>
Date:   Thu, 6 Feb 2020 16:14:19 -0800
From:   Chris Lew <clew@...eaurora.org>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     gregkh@...uxfoundation.org, arnd@...db.de, smohanad@...eaurora.org,
        jhugo@...eaurora.org, kvalo@...eaurora.org,
        bjorn.andersson@...aro.org, hemantk@...eaurora.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH v2 14/16] net: qrtr: Add MHI transport layer


On 2/4/2020 12:19 AM, Manivannan Sadhasivam wrote:
> Hi Jakub,
>
> On Mon, Feb 03, 2020 at 10:12:25AM -0800, Jakub Kicinski wrote:
>> On Fri, 31 Jan 2020 19:20:07 +0530, Manivannan Sadhasivam wrote:
>>> +/* From QRTR to MHI */
>>> +static void qcom_mhi_qrtr_ul_callback(struct mhi_device *mhi_dev,
>>> +				      struct mhi_result *mhi_res)
>>> +{
>>> +	struct qrtr_mhi_dev *qdev = dev_get_drvdata(&mhi_dev->dev);
>>> +	struct qrtr_mhi_pkt *pkt;
>>> +	unsigned long flags;
>>> +
>>> +	spin_lock_irqsave(&qdev->ul_lock, flags);
>>> +	pkt = list_first_entry(&qdev->ul_pkts, struct qrtr_mhi_pkt, node);
>>> +	list_del(&pkt->node);
>>> +	complete_all(&pkt->done);
>>> +
>>> +	kref_put(&pkt->refcount, qrtr_mhi_pkt_release);
>> Which kref_get() does this pair with?
>>
>> Looks like qcom_mhi_qrtr_send() will release a reference after
>> completion, too.
>>
> Yikes, there is some issue here...
>
> Acutally the issue is not in what you referred above but the overall kref
> handling itself. Please see below.
>
> kref_put() should be present in qcom_mhi_qrtr_ul_callback() as it will
> decrement the refcount which got incremented in qcom_mhi_qrtr_send(). It
> should be noted that kref_init() will fix the refcount to 1 and kref_get() will
> increment to 2. So for properly releasing the refcount to 0, we need to call
> kref_put() twice.
>
> So if all goes well, the refcount will get decremented twice in
> qcom_mhi_qrtr_ul_callback() as well as in qcom_mhi_qrtr_send() and we are good.
>
> But, if the transfer has failed ie., when qcom_mhi_qrtr_ul_callback() doesn't
> get called, then we are leaking the refcount. I need to rework the kref handling
> code in next iteration.
>
> Thanks for triggering this!
>
> Regards,
> Mani
>
>>> +	spin_unlock_irqrestore(&qdev->ul_lock, flags);
>>> +}

Hi Mani,

I'm not sure if this was changed in your patches but MHI is supposed to give a
ul_callback() for any packet that is successfully queued. In the case of the
transfer failing, the ul_callback() should still be called so there should
be no refcount leaking. It is an essential assumption I made, if that no longer
holds true then the entire driver needs to be reworked.

Thanks,
Chris

-- 

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