linux-kernel - Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE

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: <905897d4-7528-80a6-980d-18520069f321@gmail.com>
Date:	Tue, 9 Aug 2016 17:20:17 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Laura Abbott <labbott@...hat.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 05:13 PM, Laura Abbott wrote:
> 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.

My concern is that this is an area of the kernel where you might be
looking for stable backports, so avoiding churn in there is desireable
and if the new cache APIs become accepted and standard, since they are
building directly on top of the DMA-API, keeping them in dma-mapping.c
seems consistent.

My 2 cents.
-- 
Florian