linux-kernel - Re: [RFC PATCH 0/2] dma-unmap: allow to only unmap completed DMA buffer

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 27 May 2013 16:18:26 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Ming Lei <ming.lei@...onical.com>
cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/2] dma-unmap: allow to only unmap completed DMA
 buffer

On Tue, 28 May 2013, Ming Lei wrote:

> This patchset tries to loose the check on DMA buffer size in check_unmap()
> of dma-debug first, then only unmap the actual completed DMA buffer in USB
> unmap path.
> 
> Considered that DMA unmapping often runs in hard irq context, the patch set
> may save irq handling time. And the improvement can be observed on
> ARMv7(Pandaboard) with the chage, at average ~25us is saved about ehci irq
> handling under usbnet ping test case.

Are you aware that these changes directly contradict the advice in 
Documentation/DMA-API.txt?  That file says:

void
dma_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
                 enum dma_data_direction direction)

Unmaps the region previously mapped.  All the parameters passed in
must be identical to those passed in (and returned) by the mapping
API.

If you are going to make a change like this then you have to change the 
documentation too.  But in fact I doubt that the proposed change will 
work correctly in all circumstances.  For example, if an IOMMU is 
present.

Alan Stern

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