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: <20090402072418.GA14071@jurassic.park.msu.ru>
Date:	Thu, 2 Apr 2009 11:24:18 +0400
From:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
To:	Tejun Heo <tj@...nel.org>
Cc:	Martin Schwidefsky <schwidefsky@...ibm.com>,
	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,
	heiko.carstens@...ibm.com
Subject: Re: [GIT RFC] percpu: use dynamic percpu allocator as the default
	percpu allocator

On Thu, Apr 02, 2009 at 10:57:13AM +0900, Tejun Heo wrote:
> Martin Schwidefsky wrote:
> >> 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:
> >
> > ....
> > 
> > That would "fix" the problem as well..
> 
> Eh... I don't know.  I'd really like remove such API limitations as
> most of the necessary pieces are already there anyway, so I'd much
> prefer the re-mapping thing if it can be made to work.

On alpha, the main kernel lives in the unmapped area (superpage)
and modules get loaded into vmalloc area. Changing this means total
rewrite of the alpha code, so the remapping thing is not affordable...

On the other hand, some tricks with DEFINE_PER_CPU() are indeed possible -
for instance, using weak references we could force the compiler to
generate proper addressing mode. So DEFINE_PER_CPU(int, foo) in module
would expand to something like this:

	extern int per_cpu__foo;
	asm(".weakref per_cpu__foo, per_cpu_mod__foo");
	__attribute__((__section__(".data.percpu"))) int per_cpu_mod__foo

The main problem is that our DEFINE_PER_CPU() macro consists of more
than one definition, so it won't be possible to specify both storage class
and initializer with it.

If it's acceptable to change the semantics from

static DEFINE_PER_CPU(int, foo) = 1

to

DEFINE_PER_CPU(static, int, foo) = 1

then we're ok.

Or maybe just add STATIC_DEFINE_PER_CPU_xx() variants?

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