Messages in this thread | | | Subject | Re: [PATCH v2 14/16] net: qrtr: Add MHI transport layer | From | Chris Lew <> | Date | Tue, 11 Feb 2020 17:01:17 -0800 |
| |
On 2/10/2020 7:50 PM, Manivannan Sadhasivam wrote: > Hi Chris, > > On Thu, Feb 06, 2020 at 04:14:19PM -0800, Chris Lew wrote: >> 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. >> > Your assumption is correct. Only when the packet gets queued into the transfer > ring, the ul_xfer_cb will be called irrespective of the transfer state (success > or failure). But when the mhi_queue_transfer() returns even before queuing any > packet, then we need to decrease the refcount in the error path. > > Please correct me if I'm wrong.
The error path for mhi_queue_transfer directly frees the packet structure since no other context has a reference to those structs. If you wanted to clean it up and converge using kref release to free, I think that would work. There are some things you'll have to re-arrange like at what point the packet is added to the ul pkts list.
> Thanks, > Mani > >> Thanks, >> Chris >> >> -- >> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
| |