[Top] [All Lists]

Re: [UPDATED PATCH] IP28 support

To: Richard Sandiford <>
Subject: Re: [UPDATED PATCH] IP28 support
From: peter fuerst <>
Date: Sat, 8 Dec 2007 22:25:01 +0100 (CET)
Cc: Ralf Baechle <>, Thomas Bogendoerfer <>, Kumba <>,
In-reply-to: <871w9x6j9g.fsf@firetop.home>
Original-recipient: rfc822;
References: <> <> <> <> <87ejdx6pmh.fsf@firetop.home> <> <871w9x6j9g.fsf@firetop.home>

could text like this help to pin the assumptions down (from
"";) ?

  What cases of $N can be exempted from this measure?
  - Stack-addresses and constant (static) addresses ("sd $M,symbol+n") will not
    be used for DMA, since DMA-buffers are allocated at runtime.
  - Uncached accesses will not be done speculatively, but they fall under the
    "constant"-case already or will not be recognized at compile-time.

  Besides the DMA-problem, depending on the mis-speculation path (up to four
  branches deep), one of the frequently reused multi-purpose registers $N
  will contain some "random" value, which may be a legal but invalid kernel-
  address (say a800000061234567), reaching the memory-controller...
  However, there are cases where a register $N's content is well defined, no
  matter what (mis-)speculation path took us to this instruction:
  - The stack-pointer points to the stack from kernel-initializtion on.
  - Constant addresses ("symbol+n") are well defined "per se".
  (Luckily, legal-but-invalid doesn't occur in user mode, where no cache-
  barriers can be used. There we get either an address-error or a TLB-miss,
  leaving memory/bus untouched.)

kind regards


On Sat, 8 Dec 2007, Richard Sandiford wrote:

> Date: Sat, 08 Dec 2007 20:09:31 +0000
> From: Richard Sandiford <>
> To: Ralf Baechle <>
> Cc: Thomas Bogendoerfer <>, Kumba <>,
> Subject: Re: [UPDATED PATCH] IP28 support
> Ralf Baechle <> 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

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