linux-kernel - Re: [PATCH] dmaengine: pl08x: fix conversioin for generic unmap data

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]

Date:	Wed, 27 Nov 2013 11:55:01 -0800
From:	Dan Williams <dan.j.williams@...el.com>
To:	Olof Johansson <olof@...om.net>
Cc:	Vinod Koul <vinod.koul@...el.com>,
	"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dmaengine: pl08x: fix conversioin for generic unmap data

On Tue, Nov 26, 2013 at 8:53 PM, Olof Johansson <olof@...om.net> wrote:
> commit d38a8c622a1b ('dmaengine: prepare for generic 'unmap' data')
> added a generic unmap call but used the wrong argument for it. Fix it.
>
> Fixes: d38a8c622a1b ('dmaengine: prepare for generic 'unmap' data')
> Signed-off-by: Olof Johansson <olof@...om.net>
> ---
>
> I can't actually tell what the intent of d38a8cc622a1b and how mappings
> are expected to be managed, but it's obviously passing the wrong thing
> in here so it seems like the appropriate fix.
>

For most dma-slave usage cases the client is explicitly handling the
lifetime of the dma mappings.  It's primarily the mem-to-mem usage
cases that rely on the dma driver to do the unmapping when the
transaction is complete.  dma_descriptor_unmap() is a common
implementation rather than requiring each driver to implement it
uniquely.  Longer term we can require all clients to handle their
mapping lifetimes and remove the responsibility from the individual
drivers completely.
--
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/