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