From: "Kip Walker" <kwalker@broadcom.com>
To: linux-mips@linux-mips.org
Subject: break_cow and cache flushing
Date: Wed, 16 Oct 2002 16:53:47 -0700 [thread overview]
Message-ID: <3DADFC0B.81C8C058@broadcom.com> (raw)
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
next reply other threads:[~2002-10-16 23:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-16 23:53 Kip Walker [this message]
2002-10-17 2:04 ` break_cow and cache flushing Ralf Baechle
2002-10-17 2:09 ` Ralf Baechle
2002-10-17 2:49 ` Nigel Weeks
2002-10-17 2:49 ` Nigel Weeks
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=3DADFC0B.81C8C058@broadcom.com \
--to=kwalker@broadcom.com \
--cc=linux-mips@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.