Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1468421 > unrolled thread

[PATCH] dmaengine: pl330: Acquire dmac's spinlock in pl330_tx_status

Started byHsin-Yu Chao <hychao@chromium.org>
First post2016-08-23 11:20 +0200
Last post2016-08-23 19:10 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] dmaengine: pl330: Acquire dmac's spinlock in pl330_tx_status Hsin-Yu Chao <hychao@chromium.org> - 2016-08-23 11:20 +0200
    Re: [PATCH] dmaengine: pl330: Acquire dmac's spinlock in pl330_tx_status Guenter Roeck <groeck@google.com> - 2016-08-23 19:10 +0200

#1468421 — [PATCH] dmaengine: pl330: Acquire dmac's spinlock in pl330_tx_status

FromHsin-Yu Chao <hychao@chromium.org>
Date2016-08-23 11:20 +0200
Subject[PATCH] dmaengine: pl330: Acquire dmac's spinlock in pl330_tx_status
Message-ID<s9g2e-1UK-9@gated-at.bofh.it>
There is a racing when accessing dmac thread in pl330_tx_status that
the pl330_update is handling active request at the same time and
changing the status of descriptors. This could cause an invalid
transferred count from BUSY descriptor added up to the residual number.
Fix the bug by using the dmac's spinlock in pl330_tx_status to protect
thread resources from changing.
Note that the nested order of holding dmac's and dma_chan's spinlock is
consistent with the rest of the driver: dma_chan first and then dmac,
so it is safe from deadlock scenario.

Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
---
 drivers/dma/pl330.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 2449cb7..bd6861b 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2306,6 +2306,7 @@ pl330_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
 		goto out;
 
 	spin_lock_irqsave(&pch->lock, flags);
+	spin_lock(&pch->thread->dmac->lock);
 
 	if (pch->thread->req_running != -1)
 		running = pch->thread->req[pch->thread->req_running].desc;
@@ -2348,6 +2349,7 @@ pl330_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
 		if (desc->last)
 			residual = 0;
 	}
+	spin_unlock(&pch->thread->dmac->lock);
 	spin_unlock_irqrestore(&pch->lock, flags);
 
 out:
-- 
2.8.0.rc3.226.g39d4020

[toc] | [next] | [standalone]


#1468724

FromGuenter Roeck <groeck@google.com>
Date2016-08-23 19:10 +0200
Message-ID<s9nn4-6Up-21@gated-at.bofh.it>
In reply to#1468421
On Tue, Aug 23, 2016 at 2:16 AM, Hsin-Yu Chao <hychao@chromium.org> wrote:
> There is a racing when accessing dmac thread in pl330_tx_status that
> the pl330_update is handling active request at the same time and
> changing the status of descriptors. This could cause an invalid
> transferred count from BUSY descriptor added up to the residual number.
> Fix the bug by using the dmac's spinlock in pl330_tx_status to protect
> thread resources from changing.
> Note that the nested order of holding dmac's and dma_chan's spinlock is
> consistent with the rest of the driver: dma_chan first and then dmac,
> so it is safe from deadlock scenario.
>
> Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>

Reviewed-by: Guenter Roeck <groeck@chromium.org>

> ---
>  drivers/dma/pl330.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 2449cb7..bd6861b 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2306,6 +2306,7 @@ pl330_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
>                 goto out;
>
>         spin_lock_irqsave(&pch->lock, flags);
> +       spin_lock(&pch->thread->dmac->lock);
>
>         if (pch->thread->req_running != -1)
>                 running = pch->thread->req[pch->thread->req_running].desc;
> @@ -2348,6 +2349,7 @@ pl330_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
>                 if (desc->last)
>                         residual = 0;
>         }
> +       spin_unlock(&pch->thread->dmac->lock);
>         spin_unlock_irqrestore(&pch->lock, flags);
>
>  out:
> --
> 2.8.0.rc3.226.g39d4020
>

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web