linux-kernel - Re: [RFC v2 0/5] dmaengine: Slave DMA interface and example users

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: <20080129215453.1e3758ab@siona>
Date:	Tue, 29 Jan 2008 21:54:53 +0100
From:	Haavard Skinnemoen <hskinnemoen@...el.com>
To:	Haavard Skinnemoen <hskinnemoen@...el.com>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org,
	Shannon Nelson <shannon.nelson@...el.com>,
	David Brownell <david-b@...bell.net>, kernel@...32linux.org,
	"Francis Moreau" <francis.moro@...il.com>,
	"Paul Mundt" <lethal@...ux-sh.org>,
	"Vladimir A. Barinov" <vbarinov@...mvista.com>,
	Pierre Ossman <drzeus-list@...eus.cx>
Subject: Re: [RFC v2 0/5] dmaengine: Slave DMA interface and example users

On Tue, 29 Jan 2008 19:10:08 +0100
Haavard Skinnemoen <hskinnemoen@...el.com> wrote:

> This patch series adds the necessary interfaces to the DMA Engine
> framework to use functionality found on most embedded DMA controllers:
> DMA from and to I/O registers with hardware handshaking.

Btw, there's one issue I forgot to mention: I believe the DMA Engine
framework is currently misusing the DMA mapping API, and this patchset
makes things worse.

Currently, the async_tx bits of the API do the required calls to
dma_map_single() and/or dma_map_page(), but they rely on the driver to
do the unmapping. This is problematic since the driver doesn't have a
clue about whether it should use dma_unmap_single(), dma_unmap_page()
or something else.

The MMC driver I posted as a part of this series gets a scatterlist
from the MMC core, so it needs to use dma_map_sg() / dma_unmap_sg(). To
make this work, I decided not to do any unmapping in the DMA driver and
do the necessary dma_unmap_sg() from the DMA completion callback in the
MMC driver. Thus, for the normal async_tx operations, the buffers
aren't unmapped at all when using the dw_dmac driver. Since the
dma_unmap calls are no-ops on avr32, this doesn't have any consequences
for me in practice, but I want to use the DMA mapping API correctly
somehow.

Also, clients may want to just sync the buffer and reuse it. They can't
do that if the DMA engine driver unmaps the buffer on completion.

How do we solve this?

Haavard
--
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/