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-next>] [day] [month] [year] [list]
Message-id: <1337273586-11089-1-git-send-email-m.szyprowski@samsung.com>
Date:	Thu, 17 May 2012 18:53:03 +0200
From:	Marek Szyprowski <m.szyprowski@...sung.com>
To:	linux-arm-kernel@...ts.infradead.org,
	linaro-mm-sig@...ts.linaro.org, linux-mm@...ck.org,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:	Marek Szyprowski <m.szyprowski@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Arnd Bergmann <arnd@...db.de>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Chunsang Jeong <chunsang.jeong@...aro.org>,
	Krishna Reddy <vdumpa@...dia.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Hiroshi Doyu <hdoyu@...dia.com>,
	Subash Patel <subash.ramaswamy@...aro.org>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	Abhinav Kochhar <abhinav.k@...sung.com>,
	Tomasz Stanislawski <t.stanislaws@...sung.com>
Subject: [PATCH/RFC 0/3] ARM: DMA-mapping: new extensions for buffer sharing

Hello,

This patch series introduces a new features to DMA mapping subsystem
to let drivers share the allocated buffers (preferably using recently
introduced dma_buf framework) easy and efficient.

The first extension is DMA_ATTR_NO_KERNEL_MAPPING attribute. It is
intended for use with dma_{alloc, mmap, free}_attrs functions. It can be
used to notify dma-mapping core that the driver will not use kernel
mapping for the allocated buffer at all, so the core can skip creating
it. This saves precious kernel virtual address space. Such buffer can be
accessed from userspace, after calling dma_mmap_attrs() for it (a
typical use case for multimedia buffers). The value returned by
dma_alloc_attrs() with this attribute should be considered as a DMA
cookie, which needs to be passed to dma_mmap_attrs() and
dma_free_attrs() funtions.

The second extension is required to let drivers to share the buffers
allocated by DMA-mapping subsystem. Right now the driver gets a dma
address of the allocated buffer and the kernel virtual mapping for it.
If it wants to share it with other device (= map into its dma address
space) it usually hacks around kernel virtual addresses to get pointers
to pages or assumes that both devices share the DMA address space. Both
solutions are just hacks for the special cases, which should be avoided
in the final version of buffer sharing. To solve this issue in a generic
way, a new call to DMA mapping has been introduced - dma_get_sgtable().
It allocates a scatter-list which describes the allocated buffer and
lets the driver(s) to use it with other device(s) by calling
dma_map_sg() on it.

The proposed patches have been generated on top of the ARM DMA-mapping
redesign patch series on Linux v3.4-rc7. They are also available on the
following GIT branch:

git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git 3.4-rc7-arm-dma-v10-ext

with all require patches on top of vanilla v3.4-rc7 kernel.

Best regards
Marek Szyprowski
Samsung Poland R&D Center


Patch summary:

Marek Szyprowski (3):
  common: DMA-mapping: add DMA_ATTR_NO_KERNEL_MAPPING attribute
  ARM: dma-mapping: add support for DMA_ATTR_NO_KERNEL_MAPPING
    attribute
  ARM: dma-mapping: add support for dma_get_sgtable()

 Documentation/DMA-attributes.txt   |   18 +++++++++++++
 arch/arm/include/asm/dma-mapping.h |   12 +++++++++
 arch/arm/mm/dma-mapping.c          |   51 ++++++++++++++++++++++++++++++++----
 include/linux/dma-attrs.h          |    1 +
 include/linux/dma-mapping.h        |    3 +++
 5 files changed, 80 insertions(+), 5 deletions(-)

-- 
1.7.10.1

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ