>>>>> On 14 Mar 2002 09:39:57 +0100, Andi Kleen <ak@suse.de> said:
Andi> Rusty Russell <rusty@rustcorp.com.au> writes:
>> In message <15504.7958.677592.908691@napali.hpl.hp.com> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 15 2002 - 22:00:18 EST