dmaengine.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: dmaengine@vger.kernel.org, Michal Simek <michal.simek@xilinx.com>,
	Hyun Kwon <hyun.kwon@xilinx.com>,
	Tejas Upadhyay <tejasu@xilinx.com>,
	Satish Kumar Nagireddy <SATISHNA@xilinx.com>,
	Vinod Koul <vkoul@kernel.org>
Subject: Re: [PATCH v6 2/6] dmaengine: virt-dma: Use lockdep to check locking requirements
Date: Sat, 11 Jul 2020 22:53:38 +0300	[thread overview]
Message-ID: <20200711195338.GB5954@pendragon.ideasonboard.com> (raw)
In-Reply-To: <c4ae1bd2-eafd-136e-71f6-1d85149d776a@ti.com>

Hi Peter,

On Thu, Jul 09, 2020 at 04:07:38PM +0300, Peter Ujfalusi wrote:
> On 08/07/2020 23.19, Laurent Pinchart wrote:
> > A few virt-dma functions are documented as requiring the vc.lock to be
> > held by the caller. Check this with lockdep.
> > 
> > The vchan_vdesc_fini() and vchan_find_desc() functions gain a lockdep
> 
> vchan_vdesc_fini() is used outside of held vc->lock via vchan_complete()
> and the customized local re-implementation of it in ti/k3-udma.c
> 
> This patch did not adds the lockdep_assert_held() to the _fini.
> The vchan_complete() can be issue only in  case when the descriptor is
> set to DMA_CTRL_REUSE.

I'll drop the patch completely, I don't need it for this series. I still
think it's useful though, so if someone wants to pick it up and fix it,
please don't hesitate.

> > check as well, because, even though they are not documented with this
> > requirement (and not documented at all for the latter), they touch
> > fields documented as protected by vc.lock. All callers have been
> > manually inspected to verify they call the functions with the lock held.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> >  drivers/dma/virt-dma.c |  2 ++
> >  drivers/dma/virt-dma.h | 10 ++++++++++
> >  2 files changed, 12 insertions(+)
> > 
> > diff --git a/drivers/dma/virt-dma.c b/drivers/dma/virt-dma.c
> > index 23e33a85f033..1cb36ab3d9c1 100644
> > --- a/drivers/dma/virt-dma.c
> > +++ b/drivers/dma/virt-dma.c
> > @@ -68,6 +68,8 @@ struct virt_dma_desc *vchan_find_desc(struct virt_dma_chan *vc,
> >  {
> >  	struct virt_dma_desc *vd;
> >  
> > +	lockdep_assert_held(&vc->lock);
> > +
> >  	list_for_each_entry(vd, &vc->desc_issued, node)
> >  		if (vd->tx.cookie == cookie)
> >  			return vd;
> > diff --git a/drivers/dma/virt-dma.h b/drivers/dma/virt-dma.h
> > index e9f5250fbe4d..59d9eabc8b67 100644
> > --- a/drivers/dma/virt-dma.h
> > +++ b/drivers/dma/virt-dma.h
> > @@ -81,6 +81,8 @@ static inline struct dma_async_tx_descriptor *vchan_tx_prep(struct virt_dma_chan
> >   */
> >  static inline bool vchan_issue_pending(struct virt_dma_chan *vc)
> >  {
> > +	lockdep_assert_held(&vc->lock);
> > +
> >  	list_splice_tail_init(&vc->desc_submitted, &vc->desc_issued);
> >  	return !list_empty(&vc->desc_issued);
> >  }
> > @@ -96,6 +98,8 @@ static inline void vchan_cookie_complete(struct virt_dma_desc *vd)
> >  	struct virt_dma_chan *vc = to_virt_chan(vd->tx.chan);
> >  	dma_cookie_t cookie;
> >  
> > +	lockdep_assert_held(&vc->lock);
> > +
> >  	cookie = vd->tx.cookie;
> >  	dma_cookie_complete(&vd->tx);
> >  	dev_vdbg(vc->chan.device->dev, "txd %p[%x]: marked complete\n",
> > @@ -146,6 +150,8 @@ static inline void vchan_terminate_vdesc(struct virt_dma_desc *vd)
> >  {
> >  	struct virt_dma_chan *vc = to_virt_chan(vd->tx.chan);
> >  
> > +	lockdep_assert_held(&vc->lock);
> > +
> >  	list_add_tail(&vd->node, &vc->desc_terminated);
> >  
> >  	if (vc->cyclic == vd)
> > @@ -160,6 +166,8 @@ static inline void vchan_terminate_vdesc(struct virt_dma_desc *vd)
> >   */
> >  static inline struct virt_dma_desc *vchan_next_desc(struct virt_dma_chan *vc)
> >  {
> > +	lockdep_assert_held(&vc->lock);
> > +
> >  	return list_first_entry_or_null(&vc->desc_issued,
> >  					struct virt_dma_desc, node);
> >  }
> > @@ -177,6 +185,8 @@ static inline struct virt_dma_desc *vchan_next_desc(struct virt_dma_chan *vc)
> >  static inline void vchan_get_all_descriptors(struct virt_dma_chan *vc,
> >  	struct list_head *head)
> >  {
> > +	lockdep_assert_held(&vc->lock);
> > +
> >  	list_splice_tail_init(&vc->desc_allocated, head);
> >  	list_splice_tail_init(&vc->desc_submitted, head);
> >  	list_splice_tail_init(&vc->desc_issued, head);

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2020-07-11 19:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-08 20:19 [PATCH v6 0/6] dma: Add Xilinx ZynqMP DPDMA driver Laurent Pinchart
2020-07-08 20:19 ` [PATCH v6 1/6] dt: bindings: dma: xilinx: dpdma: DT bindings for Xilinx DPDMA Laurent Pinchart
2020-07-08 20:19 ` [PATCH v6 2/6] dmaengine: virt-dma: Use lockdep to check locking requirements Laurent Pinchart
2020-07-09 13:07   ` Peter Ujfalusi
2020-07-11 19:53     ` Laurent Pinchart [this message]
2020-07-08 20:19 ` [PATCH v6 3/6] dmaengine: Add support for repeating transactions Laurent Pinchart
2020-07-09 13:25   ` Peter Ujfalusi
2020-07-08 20:19 ` [PATCH v6 4/6] dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver Laurent Pinchart
2020-07-09 13:21   ` Peter Ujfalusi
2020-07-11 22:16     ` Laurent Pinchart
2020-07-15  6:54       ` Vinod Koul
2020-07-15 10:59   ` Vinod Koul
2020-07-16  0:41     ` Laurent Pinchart
2020-07-16  5:21       ` Vinod Koul
2020-07-16 13:46         ` Laurent Pinchart
2020-07-17  5:59           ` Vinod Koul
2020-07-08 20:19 ` [PATCH v6 5/6] dmaengine: xilinx: dpdma: Add debugfs support Laurent Pinchart
2020-07-15 11:01   ` Vinod Koul
2020-07-16  0:42     ` Laurent Pinchart
2020-07-08 20:19 ` [PATCH v6 6/6] arm64: dts: zynqmp: Add DPDMA node Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200711195338.GB5954@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=SATISHNA@xilinx.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=hyun.kwon@xilinx.com \
    --cc=michal.simek@xilinx.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=tejasu@xilinx.com \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).