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]
Message-ID: <20200820050214.GA4815@lst.de>
Date:   Thu, 20 Aug 2020 07:02:14 +0200
From:   Christoph Hellwig <hch@....de>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Tomasz Figa <tfiga@...omium.org>, Christoph Hellwig <hch@....de>,
        alsa-devel@...a-project.org, linux-ia64@...r.kernel.org,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        nouveau@...ts.freedesktop.org, linux-nvme@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        linux-mm@...ck.org, Marek Szyprowski <m.szyprowski@...sung.com>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        Joonyoung Shim <jy0922.shim@...sung.com>,
        linux-scsi@...r.kernel.org,
        Kyungmin Park <kyungmin.park@...sung.com>,
        Ben Skeggs <bskeggs@...hat.com>,
        Matt Porter <mporter@...nel.crashing.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Pawel Osciak <pawel@...iak.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        "list@....net:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
        Joerg Roedel <joro@...tes.org>,
        linux-arm-kernel@...ts.infradead.org,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        linux-parisc@...r.kernel.org, netdev@...r.kernel.org,
        Seung-Woo Kim <sw0312.kim@...sung.com>,
        linux-mips@...r.kernel.org
Subject: Re: [PATCH 05/28] media/v4l2: remove
 V4L2-FLAG-MEMORY-NON-CONSISTENT

On Wed, Aug 19, 2020 at 03:07:04PM +0100, Robin Murphy wrote:
>> FWIW, I asked back in time what the plan is for non-coherent
>> allocations and it seemed like DMA_ATTR_NON_CONSISTENT and
>> dma_sync_*() was supposed to be the right thing to go with. [2] The
>> same thread also explains why dma_alloc_pages() isn't suitable for the
>> users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT.
>
> AFAICS even back then Christoph was implying getting rid of NON_CONSISTENT 
> and *replacing* it with something streaming-API-based - i.e. this series - 
> not encouraging mixing the existing APIs. It doesn't seem impossible to 
> implement a remapping version of this new dma_alloc_pages() for 
> IOMMU-backed ops if it's really warranted (although at that point it seems 
> like "non-coherent" vb2-dc starts to have significant conceptual overlap 
> with vb2-sg).

You can alway vmap the returned pages from dma_alloc_pages, but it will
make cache invalidation hell - you'll need to use
invalidate_kernel_vmap_range and flush_kernel_vmap_range to properly
handle virtually indexed caches.

Or with remapping you mean using the iommu do de-scatter/gather?

You can implement that trivially implement it yourself for the iommu
case:

{
	merge_boundary = dma_get_merge_boundary(dev);
	if (!merge_boundary || merge_boundary > chunk_size - 1) {
		/* can't coalesce */
		return -EINVAL;
	}

	
	nents = DIV_ROUND_UP(total_size, chunk_size);
	sg = sgl_alloc();
	for_each_sgl() {
		sg->page = __alloc_pages(get_order(chunk_size))
		sg->len = chunk_size;
	}
	dma_map_sg(sg, DMA_ATTR_SKIP_CPU_SYNC);
	// you are guaranteed to get a single dma_addr out
}

Of course this still uses the scatterlist structure with its annoying
mix of input and output parametes, so I'd rather not expose it as
an official API at the DMA layer.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ