linux-kernel - Re: [GIT RFC] percpu: use dynamic percpu allocator as the default percpu allocator

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: <20090401130731.785714c5@skybase>
Date:	Wed, 1 Apr 2009 13:07:31 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, rusty@...tcorp.com.au,
	tglx@...utronix.de, x86@...nel.org, linux-kernel@...r.kernel.org,
	hpa@...or.com, Paul Mundt <lethal@...ux-sh.org>,
	rmk@....linux.org.uk, starvik@...s.com, ralf@...ux-mips.org,
	davem@...emloft.net, cooloney@...nel.org, kyle@...artin.ca,
	matthew@....cx, grundler@...isc-linux.org, takata@...ux-m32r.org,
	benh@...nel.crashing.org, rth@...ddle.net,
	ink@...assic.park.msu.ru, heiko.carstens@...ibm.com
Subject: Re: [GIT RFC] percpu: use dynamic percpu allocator as the default
 percpu allocator

On Wed, 01 Apr 2009 17:53:42 +0900
Tejun Heo <tj@...nel.org> wrote:

> Hello, Martin.
> 
> Martin Schwidefsky wrote:
> > Yes, @GOTENT is a relocation against the GOT slot that contains the
> > address of the symbol. It is a special version of @GOT that uses larl
> > to locate the got slot directly without the need of a got base pointer.
> > 
> > The code sequence with @GOT:
> > 
> > 	larl	%r12,_GLOBAL_OFFSET_TABLE_
> > 	lg	%r1,symbol@GOT(%r12)
> > 
> > is equivalent to:
> > 
> > 	larl	%r1,symbol@...ENT
> > 	lg	%r1,0(%r1)
> > 
> > The advantage of the second code sequence is that it need a single
> > register and the size of the GOT is not limited to 4K as in the first
> > example (the offset in an RX format instruction is limited to 12 bits -
> > but that is probably something you don't want to know ;-).
> 
> Maybe we can build indirection pointer manually by twiddling with
> DEFINE_PER_CPU() in such a way that it doesn't have to distinguish
> symbols and variables?

Hmm, a provocative idea: can we ban the use of static per-cpu variables
for modules in common code? There are not many common code modules
doing this, with a visibility hack I found the following relevant
locations:

block/as-iosched.c:152: warning: 'visibility' attribute ignored
crypto/sha512_generic.c:30: warning: 'visibility' attribute ignored
block/cfq-iosched.c:51: warning: 'visibility' attribute ignored
mm/kmemleak-test.c:39: warning: 'visibility' attribute ignored
kernel/rcutorture.c:117: warning: 'visibility' attribute ignored
kernel/rcutorture.c:119: warning: 'visibility' attribute ignored
drivers/acpi/processor_core.c:663: warning: 'visibility' attribute ignored
drivers/acpi/processor_thermal.c:99: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_stats.c:46: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_userspace.c:30: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_userspace.c:31: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_userspace.c:32: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_userspace.c:33: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_userspace.c:35: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_ondemand.c:90: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_conservative.c:83: warning: 'visibility' attribute igno\
red
drivers/cpufreq/freq_table.c:177: warning: 'visibility' attribute ignored
net/ipv6/syncookies.c:77: warning: 'visibility' attribute ignored

That would "fix" the problem as well..

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

--
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/