break_cow and cache flushing

break_cow and cache flushing

[Kip Walker]

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

Whew.

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

Kip

Re: break_cow and cache flushing

[Ralf Baechle]

On Wed, Oct 16, 2002 at 04:53:47PM -0700, Kip Walker wrote:

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

Ok, didn't get hold of Rik but another mm guy.  He agrees that fix is what
should be used.

Coincidentally that also explains a problem the ia64 guys were seeing :-)

  Ralf

Re: break_cow and cache flushing

[Ralf Baechle]

On Wed, Oct 16, 2002 at 04:53:47PM -0700, Kip Walker wrote:

To add a few technical details ...

> 1) 'flush_cache_page' seems to be intended for flushing virtually
> indexed dcaches when a virtual->physical mapping changes (based on
> PAddr)

Yes.

> 2) 'flush_page_to_ram' is also related to avoiding virtual aliasing in
> the dcache (based on VAddr)

Yes again.

Note that flush_page_to_ram is deprecated and should be implement as empty
function for all architecture and the other flushing mechanisms be used
instead.

> 3) 'flush_icache_page' seems to be intended for making the icache
> coherent with the dcache after an executable page has been filled

Yes.

> 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

Yes.

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

Yes, where this is getting complicated by some CPUs where remote i-caches
are coherent but the local isn't.

  Ralf

RE: break_cow and cache flushing

[Nigel Weeks]

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-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Kip Walker
Sent: Thursday, 17 October 2002 10:54
To: linux-mips@linux-mips.org
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
PAddr)
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.

Whew.

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

Kip

RE: break_cow and cache flushing

[Nigel Weeks]

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-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Kip Walker
Sent: Thursday, 17 October 2002 10:54
To: linux-mips@linux-mips.org
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
PAddr)
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.

Whew.

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

Kip