linux-kernel - Re: [PATCH 08/18] dma-mapping: add a new dma_alloc

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: <c8ea4023-3e19-d63b-d936-46a04f502a61@arm.com>
Date:   Fri, 25 Sep 2020 12:15:37 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Christoph Hellwig <hch@....de>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
        Joonyoung Shim <jy0922.shim@...sung.com>,
        Seung-Woo Kim <sw0312.kim@...sung.com>,
        Ben Skeggs <bskeggs@...hat.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Tomasz Figa <tfiga@...omium.org>,
        Matt Porter <mporter@...nel.crashing.org>,
        iommu@...ts.linux-foundation.org
Cc:     alsa-devel@...a-project.org, linux-samsung-soc@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-parisc@...r.kernel.org,
        linux-doc@...r.kernel.org, nouveau@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
        linux-mm@...ck.org, Stefan Richter <stefanr@...6.in-berlin.de>,
        netdev@...r.kernel.org, linux1394-devel@...ts.sourceforge.net,
        linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org
Subject: Re: [PATCH 08/18] dma-mapping: add a new dma_alloc_noncoherent API

On 2020-09-15 16:51, Christoph Hellwig wrote:
[...]
> +These APIs allow to allocate pages in the kernel direct mapping that are
> +guaranteed to be DMA addressable.  This means that unlike dma_alloc_coherent,
> +virt_to_page can be called on the resulting address, and the resulting

Nit: if we explicitly describe this as if it's a guarantee that can be 
relied upon...

> +struct page can be used for everything a struct page is suitable for.

[...]
> +This routine allocates a region of <size> bytes of consistent memory.  It
> +returns a pointer to the allocated region (in the processor's virtual address
> +space) or NULL if the allocation failed.  The returned memory may or may not
> +be in the kernels direct mapping.  Drivers must not call virt_to_page on
> +the returned memory region.

...then forbid this document's target audience from relying on it, 
something seems off. At the very least it's unhelpfully unclear :/

Given patch #17, I suspect that the first paragraph is the one that's no 
longer true.

Robin.