lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 14 Jan 2009 11:03:35 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	ebiederm@...ssion.com, cl@...ux-foundation.org, mingo@...e.hu,
	travis@....com, linux-kernel@...r.kernel.org, hpa@...or.com,
	akpm@...ux-foundation.org, steiner@....com, hugh@...itas.com
Subject: Re: [PATCH 13/13] x86_32: make percpu symbols zerobased on SMP

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@...nel.org>
>> Cc: Mike Travis <travis@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ