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:   Sun, 11 Dec 2016 15:07:46 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Marcus Folkesson <marcus.folkesson@...il.com>
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,
        Karol Wrona <k.wrona@...sung.com>
Subject: Re: [PATCH] iio: adc: max1027: allocate DMA-safe buffer

On 10/12/16 20:53, Marcus Folkesson wrote:
> 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.
oops. I guess that iio one snuck past us.  Karol, I doubt having this flag there
is having any effect at all on your platform.  Shall we drop it?

Marcus, it might be worth following up on the input driver as well if you would like to
do so.  I'm not so certain about what is going on in that driver as I don't know what
rmi is!

Thanks,

Jonathan
> 
> Anyway, thanks.
> 
> Cheers,
> Marcus Folkesson 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ