If you add a simple scanner for the instruction sequences that
break the Ultra and the program contains these patterns as inline
data then it will not work. If you remove the exec bit on that page
then the code around the inline data won't execute and the program
will break.
Programs which do this are pathological and not the norm.
As you mentioned, we can bounce the page between the ITLB and DTLB and
make sure it is in only one at a time in such rare cases where this
does happen.
And BTW, since I still haven't deployed a 64-bit userland, and I
control what the compilers do, I can make doubly sure this never gets
generated by the compilation system.
This all is horrible slow, does not work in all cases (inline
data), and would make JITs pretty pointless.
The JIT can be adjusted such that it makes sure that data and
instructions live in sets of pages which are disjoint. It's not that
much of a big deal.
And even for these pathological cases, the page verification is not
_that_ bad, using VIS I imagine it could be done in say 200 to 300
clock cycles. Not much more.
I can claim more accurate numbers once I know the exact instruction
patterns. For example, it might be that the instructions must sit in
a certain spot in the L1 or L2 cache, thus decreasing how many
compares must be done across the page.
Later,
David S. Miller
davem@dm.cobaltmicro.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/