[Top] [All Lists]

Re: Cannot unwind through MIPS signal frames withICACHE_REFILLS_WORKAROU

To: "Ralf Baechle" <>
Subject: Re: Cannot unwind through MIPS signal frames withICACHE_REFILLS_WORKAROUND_WAR
From: "Kevin D. Kissell" <>
Date: Tue, 13 Nov 2007 23:49:38 +0100
Cc: "Franck Bui-Huu" <>, "Andrew Haley" <>, "David Daney" <>, <>, "Richard Sandiford" <>, <>
Original-recipient: rfc822;
References: <> <> <> <> <019e01c82602$f5463bf0$10eca8c0@grendel> <>
> > True, though it should perhaps be noted that currently it's only on 4KSc/Sd
> > systems (which I know you work on) where it's even possible for the stack
> > *not* to have exec permissions, since the classical MIPS MMU gives
> > execute permission to any page that is readable.
> Disabling PROT_EXEC on a mapping tells the kernel it doesn't need to take
> care of I-cache coherency.  So it's somewhat beneficial even in absence of
> a protection bit in the actual TLB hardware.

That depends on just what the consequences of I-cache incoherence might be.
Without help from the MMU, the kernel cannot *know* that a given location
isn't in the I-cache, because a program can always compute a pointer-to-function
to an arbitrary address and dereference it successfully so long as the location
is readable.  If it's only the user who does this that will suffer as a result 
I-cache incoherence, one can argue that it serves him right.  But if it can 
up the execution of the kernel, or other user processes, I think we have to 
assume the worst.

> Some of these performance optimizations are impossible because the kernel
> can't have definate knowledge that certain addresses have never entered the
> I-cache.

Sad but true.


            Kevin K.

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