Ralf Baechle <ralf@xxxxxxxxxxxxxx> writes:
> On Sat, Dec 08, 2007 at 05:52:06PM +0000, Richard Sandiford wrote:
>> I tried to piece together (b) by asking questions in the reviews,
>> but it would be great to have a single explanation.
>>
>> The idea behind (c) is simple, of course: we insert a cache barrier
>> before the potentially-problematic stores (and, for certain
>> configurations, loads, although the original gcc patch had the
>> associated macro hard-wired to false). The key is explaining how,
>> from a compiler internals viewpoint, we decide what is "potentially-
>> problematic". This ties in with the assumptions for (b).
>
> The principle for the compiler is a store is problematic unless proven
> otherwise. A speculative store relative to the stack pointer, frame
> pointer or global pointer for example is harmless.
Right. But just so we're on the same page (and I think we probably are),
my point was that those rules aren't intrinsically obvious. They're
based on assumptions about how the code is written. For example,
it assumes there's no DMAing into stack variables. Maybe obvious,
but I think it needs to be stated explicitly. Then there's the
language-lawyerly code I gave to Peter on gcc-patches@:
void foo (int x)
{
int array[1];
if (x)
bar (array[0x1fff]);
}
This function is valid if x is never true, so we cannot assume that all
accesses off the stack and frame pointers are actually in-frame. You're
assuming either (i) the kernel doesn't use code like that or (ii) that
"garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not
trigger the problem. I imagine both are reasonable assumptions, and I'm
perfectly happy for us to make them. But they're the kind of assumption
we need to state explicitly.
Peter's patch also treated accesses to constant integer and symbolic
addresses as safe. Again, this involves making assumptions about how
constant integer and symbolic addresses are used, and this is a much
less obvious assumption than the stack one. Again, I understand that
it's a reasonable assumption to make in the linux context, but it's one
we need to pin down. E.g. there must be no run-time guarding of
target-specific constant integer IO-mapped addresses in cases where
those addresses might trigger the problem on other systems that the
same kernel image supports.
Despite appearances, I'm not trying to be awkward here ;) I just think
the assumptions are too loosely-defined at the moment (or at least too
scattered around). It would be nice to have some self-contained
description, targetted specifically at gcc and linux, that contains
anything a gcc hacker or user needs to know about the gcc patch.
Richard
