linux-kernel - Re: [PATCH 2/2] DMAENGINE: COH 901 318 fix bytesleft

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e9c3a7c21003241435j25b63c05l5df2aa44fc5dc627@mail.gmail.com>
Date:	Wed, 24 Mar 2010 14:35:01 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Linus Walleij <linus.walleij@...ricsson.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] DMAENGINE: COH 901 318 fix bytesleft

On Thu, Mar 4, 2010 at 6:40 AM, Linus Walleij
<linus.walleij@...ricsson.com> wrote:
> This makes the function to get the number of bytes left in the
> ongoing DMA transaction actually work: the old code did not take
> neither lli:s nor queued jobs into account. Also fix a missing
> spinlock while we're at it.
>
> Signed-off-by: Linus Walleij <linus.walleij@...ricsson.com>
> ----
> Sorry last version of the 0002 patch had a debug print stuck in
> it still. This one is fixed, both patches apply on top of the
> previous ones by the way, I'm digging around in this DMA driver
> now so might as well try to fix a number of issues with it.
> ---
>  drivers/dma/coh901318.c |   96 +++++++++++++++++++++++++++++++++++++++++++----
>  1 files changed, 88 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/coh901318.c b/drivers/dma/coh901318.c
> index 20889c9..f636c4a 100644
> --- a/drivers/dma/coh901318.c
> +++ b/drivers/dma/coh901318.c
[..]
> @@ -831,6 +906,7 @@ static irqreturn_t dma_irq_handler(int irq, void *dev_id)
>  static int coh901318_alloc_chan_resources(struct dma_chan *chan)
>  {
>        struct coh901318_chan   *cohc = to_coh901318_chan(chan);
> +       unsigned long flags;
>
>        dev_vdbg(COHC_2_DEV(cohc), "[%s] DMA channel %d\n",
>                 __func__, cohc->id);
> @@ -838,11 +914,15 @@ static int coh901318_alloc_chan_resources(struct dma_chan *chan)
>        if (chan->client_count > 1)
>                return -EBUSY;
>
> +       spin_lock_irqsave(&cohc->lock, flags);
> +
>        coh901318_config(cohc, NULL);
>
>        cohc->allocated = 1;
>        cohc->completed = chan->cookie = 1;
>
> +       spin_unlock_irqrestore(&cohc->lock, flags);
> +
>

Should this hunk be broken off and sent to -stable?  My guess is no.
It should be mostly impossible to trigger a problem here since the
channel is expected to be idle while resources are being allocated and
the dmaengine mutex is already protecting against parallel
allocations.  It is an unrelated fix however.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/