[PATCH] ARM: mm: avoid attempting to flush the gate_vma with VIVT caches

[gilles.chanteperdrix@xenomai.org (Gilles Chanteperdrix)]

On 07/22/2012 03:03 PM, Will Deacon wrote:
> On Sat, Jul 21, 2012 at 03:47:37PM +0100, Gilles Chanteperdrix wrote:
>> On 07/21/2012 04:40 PM, Gilles Chanteperdrix wrote:
>>> On 07/21/2012 04:35 PM, Will Deacon wrote:
>>>> Hi Gilles,
>>>>
>>>> On Sat, Jul 21, 2012 at 02:18:35PM +0100, Gilles Chanteperdrix wrote:
>>>>> On 07/20/2012 10:41 PM, Gilles Chanteperdrix wrote:
>>>>>> Being 0 or 1 whether we want to flush the vector page (I believe we do
>>>>>> not want to flush it, but am not sure).
>>>>>
>>>>> Actually, I believe we want to flush the vector page, at least on
>>>>> systems with VIVT cache: on systems with VIVT cache, the vector page is
>>>>> writeable in kernel mode, so may have been modified, and the address
>>>>> used by elf_core_dump is not the vectors address, but the address in the
>>>>> kernel direct-mapped RAM region where the vector page was allocated, so
>>>>> there is a cache aliasing issue.
>>>>
>>>> It may be writable, but we never actually write to it after it has been
>>>> initialised so there's no need to worry about caching issues (the cache is
>>>> flushed in devicemaps_init).
>>>
>>> Except if CONFIG_TLS_REG_EMUL is enabled
>>
>> is disabled I mean.
> 
> Well spotted! I disagree about the address being flushed though -- it looks
> to me like we flush from 0xffff0000 - 0xffff1000, which is what we want. Why
> do you think we're flushing from the linear mapping?

I do not think we're flushing from the linear mapping, I believe the
address used by the elf_core_dump function (elf_core_dump -> kmap ->
page_address), to copy the page data to the core is the linear mapping
address, which is the reason why we need the flush at all.

-- 
                                                                Gilles.