Messages in this thread | | | Subject | Re: [PATCH v2 14/16] net: qrtr: Add MHI transport layer | From | Chris Lew <> | Date | Thu, 6 Feb 2020 16:14:19 -0800 |
| |
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
| |