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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

Hello,

11/25/2009 07:50 PM, Ingo Molnar wrote:
> Tejun, is it perhaps a problem of the percpu code getting confused 
> between the local and file scope 'dr7' variable shadowing each other?

Yes.

> If yes then that needs to be fixed in the percpu tree. per-cpu variables 
> used to have a __per_cpu prefix and that should be maintained - the two 
> namespaces are obviously separate on the logical space, so they should 
> never overlap in the implementational space either.

If all we ever have are static variables, the prefix may be fine but
with dynamic percpu variables now basically being the same first class
citizen but prefix just doesn't cut it.  It just ends up adding more
confusion.  The transition will be a bit painful (but not too much,
how many of these reports have we had?  Only several) but after that
it's just plain local/global symbol collision the compiler would have
no problem warning about.  It behaves exactly like other global
symbols.

Percpu symbols and variables belong to a different address space than
normal symbols.  Unfortunately, C doesn't have support for such thing.
Prefixing kind of works but simply breaks when the addresses are
allowed to be handled as values.  We have had the exactly same problem
and solution for years now - iomem.  Percpu memory isn't different
from iomem at all.  Once the conversion is complete and annotations
and code are upstream, it won't be painful at all.

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/