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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux