netdev - Re: [net-next PATCH V3 0/3] Fix page_pool API and dma address storage

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]

Date:   Wed, 13 Feb 2019 22:02:38 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     brouer@...hat.com
Cc:     netdev@...r.kernel.org, linux-mm@...ck.org, toke@...e.dk,
        ilias.apalodimas@...aro.org, willy@...radead.org,
        saeedm@...lanox.com, alexander.duyck@...il.com,
        akpm@...ux-foundation.org, mgorman@...hsingularity.net,
        tariqt@...lanox.com
Subject: Re: [net-next PATCH V3 0/3] Fix page_pool API and dma address
 storage

From: Jesper Dangaard Brouer <brouer@...hat.com>
Date: Wed, 13 Feb 2019 02:55:34 +0100

> As pointed out by David Miller in [1] the current page_pool implementation
> stores dma_addr_t in page->private. This won't work on 32-bit platforms with
> 64-bit DMA addresses since the page->private is an unsigned long and the
> dma_addr_t a u64.
> 
> Since no driver is yet using the DMA mapping capabilities of the API let's
> fix this by storing the information in 'struct page' and use that to store
> and retrieve DMA addresses from network drivers.
> 
> As long as the addresses returned from dma_map_page() are aligned the first
> bit, used by the compound pages code should not be set.
> 
> Ilias tested the first two patches on Espressobin driver mvneta, for which
> we have patches for using the DMA API of page_pool.
> 
> [1]: https://lore.kernel.org/netdev/20181207.230655.1261252486319967024.davem@davemloft.net/
> 
> Signed-off-by: Jesper Dangaard Brouer <brouer@...hat.com>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@...aro.org>

Series applied, thanks Jesper.