Re: [PATCH] arch/avr32/mm/cache.c: export symbol flush_icache_range() for module using

[Hans-Christian Egtvedt <egtvedt@samfundet.no>]

Around Sun 23 Mar 2014 07:12:46 +0800 or thereabout, Chen Gang wrote:
> Is this patch OK?
> 

I reread everything you said, and it looks sane.

> If it is necessary to continue analysing more details, please let me
> know, and I will/should continue.

No, I will append it to my for-linus branch, and submit it early in the next
cycle. It should be just around the corner, Linus just released rc8 (-:

> On 03/16/2014 05:18 AM, Chen Gang wrote:
>> On 03/09/2014 11:19 PM, Chen Gang wrote:
>>> On 03/09/2014 06:17 AM, Hans-Christian Egtvedt wrote:
>>>> Around Sun 09 Mar 2014 05:47:04 +0800 or thereabout, Chen Gang wrote:
>>>>>
>>>>> After this patch, our linux kernel can pass "avr32-linux-" allmodconfig
>>>>> (it contents quite a few of warnings, but after check, I guess they are
>>>>> not kernel's issue).
>>>>
>>>> That sounds great, I am a bit surprised however that the lkdtm module need
>>>> flush_icache_range. Would have been interesting to look into what causes this
>>>> dependency.
>>>>
>> 
>> After read a little more details for lkdtm, I guess "after overwrite an
>> executable area by do_nothing(), it needs flush_icache_range() to be
>> sure the new instructions/data must have effect with all cpu".
>> 
>> Welcome any additional information for it.
>> 
>> Thanks.
>> 
>>>
>>> "driver/misc/lkdtm.c" will use this flush_icache_range().
>>>
>>> And some architectures export it to modules.
>>>
>>>   [root@gchen arch]# grep -rn flush_icache_range * | grep EXPORT
>>>   arm64/mm/flush.c:105:EXPORT_SYMBOL(flush_icache_range);
>>>   avr32/mm/cache.c:114:EXPORT_SYMBOL(flush_icache_range);
>>>   m68k/mm/cache.c:106:EXPORT_SYMBOL(flush_icache_range);
>>>   mn10300/mm/cache-inv-icache.c:129:EXPORT_SYMBOL(flush_icache_range);
>>>   mn10300/mm/cache-flush-icache.c:155:EXPORT_SYMBOL(flush_icache_range);
>>>   sparc/mm/init_64.c:435:EXPORT_SYMBOL(flush_icache_range);
>>>
>>> Welcome any more details information by any other members, thanks.
>> 
>> Thanks.
-- 
mvh
Hans-Christian Egtvedt