[Top] [All Lists]

Re: RM7k cache_flush_sigtramp

To: Ralf Baechle <>
Subject: Re: RM7k cache_flush_sigtramp
From: Fuxin Zhang <>
Date: Wed, 06 Aug 2003 23:04:19 +0800
Cc: Adam Kiepul <>, MAKE FUN PRANK CALLS <>
In-reply-to: <>
Original-recipient: rfc822;
References: <9DFF23E1E33391449FDC324526D1F259017DF091@SJC1EXM02> <> <> <> <>
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Ralf Baechle wrote:

If the new process touch the cow page first,shouldn't it get a new page and leave the original page for parent? If so,the parent should be able to see the trampoline content from icache anyway(either L2 or memory should
have the value),though the child may not?

RM7000 has a physically indexed cache.  That means if the copy of the
page wasn't explicitly or implicitly written back to L2 the process
whichever ends up with the copy of the page might fetch stale instructions
from memory - boom.

not been flushed proplerly in the previous step, thereby failing to
execute the trampoline - crash.

RM7000 has 16k 4-way set-associated primary caches,which are supposed to have no cache aliasing problem

The described scenario is not an aliasing problem; it's the case where the
copy of the cow page hasn't properly been flushed at all.  When we
isolated the bug was that neither flush_page_to_ram() nor flush_cache_page()
were flushing the cache.  I suspect your case must be something fairly
After cache rewrite,flush_page_to_ram is null; and in this case flush_cache_page do nothing for a stack page. (It flushes only when has_dc_aliases or exec set). So the one use the new copy will have problem ?! Am I missing something?

Thank you very much, great Ralf:).



<Prev in Thread] Current Thread [Next in Thread>