linux-kernel - RE: [PATCH 1/2] dma-mapping: check dma

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, 23 Feb 2022 14:57:26 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Christoph Hellwig' <hch@....de>, Baoquan He <bhe@...hat.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "cl@...ux.com" <cl@...ux.com>,
        "42.hyeyoo@...il.com" <42.hyeyoo@...il.com>,
        "penberg@...nel.org" <penberg@...nel.org>,
        "rientjes@...gle.com" <rientjes@...gle.com>,
        "iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "david@...hat.com" <david@...hat.com>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "steffen.klassert@...unet.com" <steffen.klassert@...unet.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
        "gor@...ux.ibm.com" <gor@...ux.ibm.com>,
        "agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
        "borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
        "svens@...ux.ibm.com" <svens@...ux.ibm.com>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "michael@...le.cc" <michael@...le.cc>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "wsa@...nel.org" <wsa@...nel.org>
Subject: RE: [PATCH 1/2] dma-mapping: check dma_mask for streaming mapping
 allocs

From: Christoph Hellwig
> Sent: 23 February 2022 14:26
> 
> On Wed, Feb 23, 2022 at 08:28:13AM +0800, Baoquan He wrote:
> > Could you tell more why this is wrong? According to
> > Documentation/core-api/dma-api.rst and DMA code, __dma_alloc_pages() is
> > the core function of dma_alloc_pages()/dma_alloc_noncoherent() which are
> > obviously streaming mapping,
> 
> Why are they "obviously" streaming mappings?
> 
> > why do we need to check
> > dev->coherent_dma_mask here? Because dev->coherent_dma_mask is the subset
> > of dev->dma_mask, it's safer to use dev->coherent_dma_mask in these
> > places? This is confusing, I talked to Hyeonggon in private mail, he has
> > the same feeling.
> 
> Think of th coherent_dma_mask as dma_alloc_mask.  It is the mask for the
> DMA memory allocator.  dma_mask is the mask for the dma_map_* routines.

I suspect it is all to allow for things like:
- A 64bit system with memory above 4G.
- A device that can only generate 32bit addresses.
- Some feature of the memory system (or bus bridges) that restricts
  cache snooping to the low 1G of address space.

So dma_alloc_coherent() has to allocate memory below 1G.
The dma_map functions have to use bounce-buffers for addresses
  above 4G.
dma_alloc_noncoherent() can allocate anything below 4G and so
  avoid bounce buffers later on.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)