Re: [PATCH 13/13] x86_32: make percpu symbols zerobased on SMP

[Tejun Heo <tj@kernel.org>]

Hello, Rusty.

Rusty Russell wrote:
> On Tuesday 13 January 2009 21:08:17 Tejun Heo wrote:
>> This patch makes percpu symbols zerobased on x86_32 SMP by using
>> PERCPU_VADDR() with 0 vaddr in vmlinux_32.lds.S.  A new PHDR is added
>> as existing ones cannot contain sections near address zero.
> ...
>> Signed-off-by: Tejun Heo <tj@kernel.org>
>> Cc: Mike Travis <travis@sgi.com>
>> ---
>>  arch/x86/kernel/cpu/common.c     |    8 ++++++++
>>  arch/x86/kernel/head_32.S        |   37 ++++++++++++++++++++++++++++++++++---
>>  arch/x86/kernel/setup_percpu.c   |    4 ----
>>  arch/x86/kernel/vmlinux_32.lds.S |   16 +++++++++++++++-
>>  4 files changed, 57 insertions(+), 8 deletions(-)
> 
> Hmm, the only reason for this change is to unify with 64-bit, yes?  Yet it
> doesn't actually win us anything on that front, as this diffstat shows.

Yeah and to simplify things for future changes.  In this patch, the
only actual unification is in __per_cpu_offset initialization but the
lack of unification is partly due to the usage of pda and differences
in initialization sequence, which again couldn't be unified because
percpu handling was different, so it's a tied knot and this patch
helps untangling it.  Also, with cpualloc (or whatever) scheduled, I
think it's better to have two percpu models, up and smp, even if it
costs 49 more lines.

> If gcc's -mcmodel=kernel had used a weak symbol for the offset of the stack
> canary, we would have been happy.  Unfortunately generic per-cpu and x86-64
> PDA were developed separately, so noone realize the problem until too late.

And we seem to be stuck with it if we want to keep compatibility with
compilers.  :-(

> The basic series looks good: it will clash with my per-cpu work (mainly
> because I remove the per_cpu__ prefix) in a purely-textual way though.

I thought about removing all explicit per_cpu__ prefixes with
per_cpu_var() but the usage seemed prevalent so left it alone.  Why
remove it BTW?

Thanks.

-- 
tejun