(The PowerPC only really needs to flush executable pages, as the
data cache is coherent, but the instruction cache isn't. The kernel
does not make this distinction. Pre-zeroed pages have the advantage
of being already flushed. Some day I'll count how many unnecessary
flushes happen and decide if this is important.)
There are some ways to avoid this problem if you're diligent.
If the processor can tell you, at fault/tlb-miss time that the
translation is for an instruction access you can do the following:
1) Any newly allocated page, be it for the page cache, anonymous
memory, etc. is marked initially as "I-cache unclean"
2) Until an instruction access fault is made to the page, it
remains in this state.
3) During an instruction access, if the page is still marked
as "I-cache unclean", branch out to slower code which performs
the flush, removes the "I-cache unclean" marking from the
page and proceeds with normal fault processing.
As an optimization you can store the page "I-cache unclean" state
in the PTEs. The way this works is, when a page mapping is created
(all of which you can catch via your include/asm/pgtable.h interfaces)
you check the page struct for that physical page for I-cache state,
and propagate it into a PTE software state bit. The fault/tlb-miss
code for instruction access cases in #3 above is extended to
check the PTE software bit so it does not have to walk all the way
to the page struct to obtain the "I-cache unclean" state.
This mechanism has several other uses as well. It can be used to
workaround CPU hardware bugs which would be visible to the user.
Instead of "I-cache unclean" the state becomes "page has instruction
sequence which could trigger CPU bug X". Instead of an I-cache
flush, you rather perform a scan of the page looking for the CPU bug
triggering code sequences.
One caveat with using this to workaround CPU bugs is that one needs to
deal with the complex case of dynamic linking where instructions are
written by the userland code, if the CPU implements ELF dynamic
linking this way. My suggestion in such a case would be to make the
dynamic linker make special kernel calls which say "Please write to
here this(these) instruction(s)" so the kernel can re-validate the
page all in one go. If you don't do something like this then the page
mapping would thrash in the TLB since if the user writes to the page,
you can't allow execution to it until you re-validate it again.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/