linux-kernel - Re: data consistency of high page

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <BANLkTimKw3mg8N-gBxh3jbo9msaHOF3qPA@mail.gmail.com>
Date:	Tue, 5 Apr 2011 17:17:23 +0900
From:	NamJae Jeon <linkinjeon@...il.com>
To:	Minchan Kim <minchan.kim@...il.com>
Cc:	Ralf Baechle <ralf@...ux-mips.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-mips <linux-mips@...ux-mips.org>
Subject: Re: data consistency of high page

Hi.

As you know, there is cache operation about highpage in arm arch.

arch/arm/mm/flush.c
-----------------------------------------------------------------------------------------------
if (!PageHighMem(page)) {
                __cpuc_flush_dcache_area(page_address(page), PAGE_SIZE);
        } else {
                void *addr = kmap_high_get(page);
                if (addr) {
                        __cpuc_flush_dcache_area(addr, PAGE_SIZE);
                        kunmap_high(page);
                } else if (cache_is_vipt()) {
                        /* unmapped pages might still be cached */
                        addr = kmap_atomic(page);
                        __cpuc_flush_dcache_area(addr, PAGE_SIZE);
                        kunmap_atomic(addr);
                }
        }
-------------------------------------------------------------------------------------------------

currently, mips kernel just return without cache operation.

Would you plz tell me your opinion ?

Thanks.


2010/3/23 NamJae Jeon <linkinjeon@...il.com>:
> Hi. Ralf.
>
> I'm Namjae.jeon. nice to meet you.
>
> I face cache aliasing problem on mips 34ke.
>
> Our target cache is 34kB 4way i/d-cache , 32bytes linesize.
>
> As you know, there is possibility of cache aliasing on 8kB per way.
>
> But mips arch of kernel mainline can not properly  handile this case.
>
> For example, highmem handling in __fluash_dcache_page function is just return.
>
> So, if argument page is page in highmem, it can not flush in dcache line.
>
> I want to listen your opinion.
>
> Thanks.
>
>
> 2010/3/23 Minchan Kim <minchan.kim@...il.com>:
>> Hi, Ralf.
>>
>> Below is thread long time ago.
>> At that time, we can't end up the problem by some reason.
>> Sorry for that.
>>
>> The problem would occur, again.
>>
>> On Fri, Oct 16, 2009 at 6:24 PM, Ralf Baechle <ralf@...ux-mips.org> wrote:
>>> On Fri, Oct 16, 2009 at 02:17:19PM +0900, Minchan Kim wrote:
>>>
>>>> Many code of kernel fs usually allocate high page and flush.
>>>> But flush_dcache_page of mips checks PageHighMem to avoid flush
>>>> so that data consistency is broken, I think.
>>>
>>> What processor and cache configuration?
>>>
>>>> I found it's by you and Atsushi-san on 585fa724.
>>>> Why do we need the check?
>>>> Could you elaborte please?
>>>
>>> The if statement exists because __flush_dcache_page would crash if a page
>>> is not mapped.  This of course isn't correct but that wasn't a problem
>>> since highmem still is only supported on machines that don't have aliases.
>>>
>>>  Ralf
>>>
>>
>> Our system is following as.
>>
>> mips 34ke
>> primary i-cache 32kB VIPT 4way 32 byte line size.
>> primary d-cache 32kB 4way  32 bytes linesize
>>
>> If you have further questions, Namjae, Could you follow question of Ralf?
>>
>> --
>> Kind regards,
>> Minchan Kim
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/