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.
Thanks,
Mani
> Thanks,
> Chris
>
> --
>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
