Re: [PATCH] 2.5.1-pre5: per-cpu areas

[David Mosberger]

>>>>> On 14 Mar 2002 09:39:57 +0100, Andi Kleen <[e-mail]> said:

  Andi> Rusty Russell <[e-mail]> writes:
  >> In message <[e-mail]> you
  >> write: > OK, I see this.  Unfortunately, HIDE_RELOC() causes me
  >> problems > because it prevents me from taking the address of a
  >> per-CPU variable.  > This is useful when you have a per-CPU
  >> structure (e.g., cpu_info).  > Perhaps there should/could be a
  >> version of HIDE_RELOC() that doesn't > dereference the resulting
  >> address?
  >>
  >> Yep, valid point.  Patch below: please play.

  Andi> Please don't do that. I cannot easily take the address of a
  Andi> per CPU variable on x86-64, or rather only with additional
  Andi> overhead. If you need the address of one please use a
  Andi> different macro for that.

Actually, I'm somewhat sympathetic to Andi's point.  One issue I'm
concerned about is what the meaning is of:

	&this_cpu(foo)

Suppose CPU1 calculates this pointer and then passes it off to CPU2.
Now what version of "foo" will this pointer access on CPU2?  Depending
on implemenation, it might be either CPU1's local variable or CPU2's
local variable (the default per-CPU variable would do the former, an
implementation based on TLB remapping would do the latter).

How about the following proposal:

	- taking the address of this_cpu(var) is never allowed (can be
          enforced with RELOC_HIDE())

	- taking the address of per_cpu(var, n) is always legal and
	  will return a pointer which will access CPU n's version of
	  the variable, no matter what CPU dereferences the pointer

Andi, I think this would take care of the x86-64 problem as well, right?

	--david