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:	Tue, 9 Aug 2016 17:13:04 -0700
From:	Laura Abbott <labbott@...hat.com>
To:	Florian Fainelli <f.fainelli@...il.com>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	John Stultz <john.stultz@...aro.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Riley Andrews <riandrews@...roid.com>
Cc:	devel@...verdev.osuosl.org, Jon Medhurst <tixy@...aro.org>,
	Android Kernel Team <kernel-team@...roid.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Will Deacon <will.deacon@....com>,
	Russell King <linux@...linux.org.uk>,
	linux-kernel@...r.kernel.org, linaro-mm-sig@...ts.linaro.org,
	Rohit kumar <rohit.kr@...sung.com>,
	Bryan Huntsman <bryanh@...eaurora.org>,
	Jeremy Gebben <jgebben@...eaurora.org>,
	Eun Taik Lee <eun.taik.lee@...sung.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Liviu Dudau <Liviu.Dudau@....com>,
	Mitchel Humpherys <mitchelh@...eaurora.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE

On 08/09/2016 02:56 PM, Florian Fainelli wrote:
> On 08/08/2016 10:49 AM, Laura Abbott wrote:
>> arm may need the kernel_force_cache APIs to guarantee data consistency.
>> Implement versions of these APIs based on the DMA APIs.
>>
>> Signed-off-by: Laura Abbott <labbott@...hat.com>
>> ---
>>  arch/arm/include/asm/cacheflush.h |   4 ++
>>  arch/arm/mm/dma-mapping.c         | 119 --------------------------------------
>>  arch/arm/mm/flush.c               | 115 ++++++++++++++++++++++++++++++++++++
>
> Why is the code moved between dma-mapping.c and flush.c? It was not
> obvious while looking at these patches why this is needed.
>

I wanted to use the cache flushing routines from dma-mapping.c and
it seemed better to pull them out vs. trying to put more generic
cache flushing code in dma-mapping.c. flush.c seemed like an
appropriate place although I forgot about the dependency on CONFIG_MMU.
It can certainly remain in dma-mapping.c if deemed appropriate.

Thanks,
Laura

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ