From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Vinod Koul <vinod.koul@intel.com>,
Mark Brown <broonie@kernel.org>, Simon <horms@verge.net.au>,
Nguyen Viet Dung <nv-dung@jinso.co.jp>,
Magnus <magnus.damm@gmail.com>,
Linux-SH <linux-sh@vger.kernel.org>,
Linux-ALSA <alsa-devel@alsa-project.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Cao Minh Hiep <cm-hiep@jinso.co.jp>,
sakato <ryusuke.sakato.bx@renesas.com>,
dmaengine@vger.kernel.org
Subject: Re: [PATCH 1/4] dmaengine: rcar-dmac: fixup spinlock in rcar-dmac
Date: Wed, 20 May 2015 08:25:19 +0000 [thread overview]
Message-ID: <2119137.Ez4XYKtCXC@avalon> (raw)
In-Reply-To: <871tib52vy.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
Thank you for the patch.
On Wednesday 20 May 2015 03:46:19 Kuninori Morimoto wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Current rcar-dmac driver is using spin_lock_irq() / spin_unlock_irq()
> in some functions. But, some other driver might call DMAEngine API
> during interrupt disabled. In such case, rcar-dmac side spin_unlock_irq()
> forcefully allows all interrupts. Therefore, other driver receives
> unexpected interruption, and its exclusive access control will be broken.
> This patch replaces spin_lock_irq() to spin_lock_irqsave(),
> and spin_unlock_irq() to spin_unlock_irqrestore().
I would have sworn I had fixed the issue already :-/ Sorry about it.
I believe (part of) the issue should be fixed in the DMA engine API by
splitting descriptor allocation to non-atomic context, but that's a longer
term solution of course, out of scope for this series.
The patch looks good, please see below for a couple of comments.
> Reported-by: Cao Minh Hiep <cm-hiep@jinso.co.jp>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Tested-by: Keita Kobayashi <keita.kobayashi.ym@renesas.com>
> ---
> drivers/dma/sh/rcar-dmac.c | 55 +++++++++++++++++++++++------------------
> 1 file changed, 31 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index a18d16c..6a5d4b9 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
[snip]
> @@ -964,12 +969,13 @@ static void rcar_dmac_free_chan_resources(struct
> dma_chan *chan) struct rcar_dmac *dmac = to_rcar_dmac(chan->device);
> struct rcar_dmac_desc_page *page, *_page;
> struct rcar_dmac_desc *desc;
> + unsigned long flags;
> LIST_HEAD(list);
>
> /* Protect against ISR */
> - spin_lock_irq(&rchan->lock);
> + spin_lock_irqsave(&rchan->lock, flags);
The .device_free_chan_resources() can't be called with interrupts disabled, so
we should be safe with spin_lock_irq() here. However, as the function isn't
called in a performance-critical path, I'm fine with spin_lock_irqsave() too.
> rcar_dmac_chan_halt(rchan);
> - spin_unlock_irq(&rchan->lock);
> + spin_unlock_irqrestore(&rchan->lock, flags);
>
> /* Now no new interrupts will occur */
>
> @@ -1351,8 +1357,9 @@ static irqreturn_t rcar_dmac_isr_channel_thread(int
> irq, void *dev) {
> struct rcar_dmac_chan *chan = dev;
> struct rcar_dmac_desc *desc;
> + unsigned long flags;
>
> - spin_lock_irq(&chan->lock);
> + spin_lock_irqsave(&chan->lock, flags);
Isn't the threaded IRQ handler called in a thread with interrupts enabled by
definition ? spin_lock_irq() should thus be safe here. You could, however,
convince me that spin_lock_irqsave() won't make much of a difference
performance-wise, and would allow avoiding future similar bugs.
> /* For cyclic transfers notify the user after every chunk. */
> if (chan->desc.running && chan->desc.running->cyclic) {
> @@ -1364,9 +1371,9 @@ static irqreturn_t rcar_dmac_isr_channel_thread(int
> irq, void *dev) callback_param = desc->async_tx.callback_param;
>
> if (callback) {
> - spin_unlock_irq(&chan->lock);
> + spin_unlock_irqrestore(&chan->lock, flags);
> callback(callback_param);
> - spin_lock_irq(&chan->lock);
> + spin_lock_irqsave(&chan->lock, flags);
> }
> }
>
> @@ -1381,20 +1388,20 @@ static irqreturn_t rcar_dmac_isr_channel_thread(int
> irq, void *dev) list_del(&desc->node);
>
> if (desc->async_tx.callback) {
> - spin_unlock_irq(&chan->lock);
> + spin_unlock_irqrestore(&chan->lock, flags);
> /*
> * We own the only reference to this descriptor, we can
> * safely dereference it without holding the channel
> * lock.
> */
> desc->async_tx.callback(desc->async_tx.callback_param);
> - spin_lock_irq(&chan->lock);
> + spin_lock_irqsave(&chan->lock, flags);
> }
>
> list_add_tail(&desc->node, &chan->desc.wait);
> }
>
> - spin_unlock_irq(&chan->lock);
> + spin_unlock_irqrestore(&chan->lock, flags);
>
> /* Recycle all acked descriptors. */
> rcar_dmac_desc_recycle_acked(chan);
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2015-05-20 8:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 3:45 [PATCH 0/4] ASoC: rsnd: fixup interrupt / spin lock issue Kuninori Morimoto
2015-05-20 3:46 ` [PATCH 1/4] dmaengine: rcar-dmac: fixup spinlock in rcar-dmac Kuninori Morimoto
2015-05-20 8:25 ` Laurent Pinchart [this message]
2015-05-20 3:46 ` [PATCH 2/4] ASoC: rsnd: indicate unknown HW start Kuninori Morimoto
2015-05-20 3:47 ` [PATCH 3/4] ASoC: rsnd: add rsnd_dai_stream_quit() Kuninori Morimoto
2015-05-20 3:47 ` [PATCH 4/4] ASoC: rsnd: spin lock for interrupt handler Kuninori Morimoto
2015-05-20 6:12 ` [PATCH 0/4] ASoC: rsnd: fixup interrupt / spin lock issue Cao Minh Hiep
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=2119137.Ez4XYKtCXC@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cm-hiep@jinso.co.jp \
--cc=dmaengine@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=horms@verge.net.au \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=nv-dung@jinso.co.jp \
--cc=ryusuke.sakato.bx@renesas.com \
--cc=vinod.koul@intel.com \
/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