All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fuxin Zhang <fxzhang@ict.ac.cn>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>,
	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
Date: Wed, 06 Aug 2003 23:04:19 +0800	[thread overview]
Message-ID: <3F3118F3.1030001@ict.ac.cn> (raw)
In-Reply-To: <20030806144513.GB12161@linux-mips.org>



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:).

>similar.
>
>  Ralf
>
>
>  
>

  reply	other threads:[~2003-08-06 15:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-01 15:42 RM7k cache_flush_sigtramp Adam Kiepul
2003-08-04  3:38 ` Fuxin Zhang
2003-08-06 11:00 ` Fuxin Zhang
2003-08-06 11:55   ` Ralf Baechle
2003-08-06 12:52     ` Fuxin Zhang
2003-08-06 14:45       ` Ralf Baechle
2003-08-06 15:04         ` Fuxin Zhang [this message]
2003-08-06 22:30           ` Ralf Baechle
  -- strict thread matches above, loose matches on Subject: below --
2003-07-31 16:50 Adam Kiepul
2003-08-01  0:40 ` Fuxin Zhang
2003-08-01  3:01   ` Ralf Baechle
2003-08-01  4:59     ` Fuxin Zhang
2003-08-01  7:51 ` Dominic Sweetman
2003-08-01  7:51   ` Dominic Sweetman
2003-08-01  9:26   ` Ralf Baechle
2003-08-01 14:18     ` Fuxin Zhang
2003-08-02 17:02       ` Ralf Baechle
2003-08-04  8:45     ` Dominic Sweetman
2003-08-04 11:51       ` Maciej W. Rozycki
2003-07-31  1:56 Fuxin Zhang
2003-07-31 11:46 ` Ralf Baechle
2003-07-31 12:57   ` Fuxin Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F3118F3.1030001@ict.ac.cn \
    --to=fxzhang@ict.ac.cn \
    --cc=Adam_Kiepul@pmc-sierra.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.