Re: linux-next: manual merge of the rr tree

[David Miller <davem@davemloft.net>]

From: Christoph Lameter <cl@linux-foundation.org>
Date: Fri, 9 Jan 2009 08:42:09 -0600 (CST)

> On Thu, 8 Jan 2009, David Miller wrote:
> 
> > Otherwise, if overflow is possible, tranforming an array index
> > comparison into a pointer comparison is no longer legal.
> 
> This means that access to an object immediately before or after would wrap
> around. If the object is not near 0 or near the end of the address space
> then such a thing cannot occur. We have the ZERO page at address 0 so the
> lower end is taken care and usually there are also special uses for very
> high addresses.

GCC, or any compiler, cannot know about such invariants.
What it does know is that it can always transform
comparisons between "i" and "max_i" into comparisons
between '&array[i]' and '&array[max_i]'

> The wrapping is mainly an issue if the percpu area is linked to very high
> addresses but later the per cpu areas for the individual processors are
> allocated on relatively low addresses. The address calculation of the
> location of a percpu address for a particular cpu then occurs by
> adding an offset that will wrap around zero. This is fine on x86.

Anyways, the original reason for the RELOC_HIDE business is that GCC
would do common subexpression elimination on the address computation.
The percpu stuff was a calculation using a symbol address as some kind
of base, and GCC took liberties with that (which were legal given
the amount of information we (weren't) giving to it).

I honestly forget the exact details, I'm sure Rusty could explain...