linux-kernel - Re: linux-next: percpu tree build warning

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]

Message-ID: <4B0D2585.90909@kernel.org>
Date:	Wed, 25 Nov 2009 21:39:33 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Rusty Russell <rusty@...tcorp.com.au>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Lameter <cl@...ux-foundation.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: linux-next: percpu tree build warning

Hello,

11/25/2009 08:58 PM, Ingo Molnar wrote:
> percpu variables are basically in a special struct. It's not like you 
> can _ever_ access 'dr7' the percpu variable like that - it _always_ has 
> to go via a proper percpu wrapper construct. So this change is 
> needlessly obtrusive.

The only problem is that now the addresses can and need be handled as
value.  If we keep the prefix, we just end up with one set of
accessors which prepend prefix to the symbol string and another set
which are basically the same but lack any protection (we already have
them - this_cpu accessors).  The current for-next tree is sort of
caught up inbetween.  Once sparse warning cleanup sweep is complete,
all static specific accessors will be dropped.

> Really, guys, while the workaround is easy (a rename), this might be 
> going a bit too far. I already think that the recently introduced 
> limitation to name local percpu symbols globally sucked - but i'm not 
> sure whether this new rule of not allowing such clear and clean looking 
> code is acceptable.
>
> Percpu variables now pollute _both_ the global and the local namespace - 
> i dont think you can have it both ways.

I agree static local symbol requiring global uniqueness truly sucks
but this is a completely different issue.  This is making percpu
variables behave more sanely and the fallouts are few and linux-next
warning check is enough to detect the few.

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/