[Top] [All Lists]

RE: break_cow and cache flushing

To: "Linux-Mips \(E-mail\)" <>
Subject: RE: break_cow and cache flushing
From: "Nigel Weeks" <>
Date: Thu, 17 Oct 2002 13:49:03 +1100
Importance: Normal
In-reply-to: <>
Original-recipient: rfc822;
Reply-to: <>
MOO!, Don't hurt me, MOOOO!!!!

(cow collapses against the fence, twitching and subsiding into silience, as
the farmer loads the offcut onto the carry-all)

sorry, just had to...

-----Original Message-----
[]On Behalf Of Kip Walker
Sent: Thursday, 17 October 2002 10:54
Subject: break_cow and cache flushing

Can anyone comment on the following observations:

1) 'flush_cache_page' seems to be intended for flushing virtually
indexed dcaches when a virtual->physical mapping changes (based on
2) 'flush_page_to_ram' is also related to avoiding virtual aliasing in
the dcache (based on VAddr)
3) 'flush_icache_page' seems to be intended for making the icache
coherent with the dcache after an executable page has been filled
4) 'break_cow' may copy an executable page that is marked executable,
for example a stack page (which has VM_EXEC) and might contain a live
signal trampoline

On a CPU with writeback physically indexed/tagged dcache and virtually
indexed icache that isn't coherent with the dcache, (1) and (2) are NOPs
and (3) must writeback the dcache and flush the icache.

BUT either my understanding of (1) or (2) is wrong, or 'break_cow' needs
to do a 'flush_icache_page' when the page is executable.  Consider the
following (evil) case.

A process takes a signal, and calls 'fork' from the handler.  The signal
trampoline is sitting in the stack, and both processes end up with the
stack page COW.  The parent ends up breaking the COW and so it gets the
new copy of the page, but if the caches aren't flushed, it may execute
garbage from the old contents of the new stack page.


I've verified that doing a 'flush_icache_page' in 'break_cow' whenever
an executable page is copied (which shouldn't be too often, I'd guess)
and leaving 'flush_cache_page' and 'flush_page_to_ram' as NOPs seems
stable (and fixes the previously crashing case described above).


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