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: <20161210205333.24gjh6vccyqdo5ll@gmail.com>
Date:   Sat, 10 Dec 2016 21:53:33 +0100
From:   Marcus Folkesson <marcus.folkesson@...il.com>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Matt Ranostay <mranostay@...il.com>,
        Sandhya Bankar <bankarsandhya512@...il.com>,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: adc: max1027: allocate DMA-safe buffer

On Sat, Dec 10, 2016 at 05:36:34PM +0000, Jonathan Cameron wrote:
> On 09/12/16 10:24, Marcus Folkesson wrote:
> > The buffer needs to be DMA-safe when used with spi_read()
> > 
> > Signed-off-by: Marcus Folkesson <marcus.folkesson@...il.com>
> Please read the documentation in include/linux/gfp.h about GFP_DMA.
> 
> Specifically:
> 220  * GFP_DMA exists for historical reasons and should be avoided where possible.
> 221  *   The flags indicates that the caller requires that the lowest zone be
> 222  *   used (ZONE_DMA or 16M on x86-64). Ideally, this would be removed but
> 223  *   it would require careful auditing as some users really require it and
> 224  *   others use the flag to avoid lowmem reserves in ZONE_DMA and treat the
> 225  *   lowest zone as a type of emergency reserve.
> 
> Seems unlikely this applies!  This caught me by surprise as I didn't even know
> that flag existed - hence I went digging.
> 
> Jonathan

Always learn something!
I did not know it was depricated, seems like the comment about GFP_DMA was
commited just a year ago.

I had a problem with a driver on my own that by using a non
DMA-safe buffer, so I was digging around looking for similiar cases in
the kernel.

I thought other drivers (iio/common/ssp_sensors/sspi_spi.c,
input/rmi4/rmi_spi.c) was using GFP_DMA for this purpose.

Anyway, thanks.

Cheers,
Marcus Folkesson 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ