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: <20090401103257.12c2517e@skybase>
Date:	Wed, 1 Apr 2009 10:32:57 +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:17:33 +0900
Tejun Heo <tj@...nel.org> wrote:

> Martin Schwidefsky wrote:
> > Is the goal to use the same access macros for both dynamically and
> > statically allocated percpu variables? That would make the proposed
> > solution impractical.
> 
> Yeah, it's one of the goals so that we don't have to have two sets of
> APIs (e.g. the fast percpu_*() accessors).

Uh-oh..
 
> > The "X" constraint trick we used so far tells the compiler to pass the
> > argument verbatim to the assembler. The assembler knows how to deal
> > with symbol@...ENT. If we pass a gcc variable or even a more general
> > term via an "X" constraint the assembler gets <something C-ish>@GOTENT.
> > It is not possible to parse this in the assembler. To do what you want
> > to achieve would mean to avoid using the "X" constraint. Which means
> > that we cannot use the GOTENT trick anymore. If we let the compiler
> > resolve the address for a static per cpu variable we end up with the
> > larl problem. Ouch!
> > 
> > So far the SHIFT_PERCPU_PTR/SHIFT_PERCPU_VAR is the only solution
> > I have found for s390 and the dynamic percpu allocator. I'll keep
> > looking for a better solution but I am not optimistic.
> 
> What does the assembler do when it gets GOTENT?  GOTENT sounds like
> global offset table entry, so does it make the assembler emit an entry
> in GOT and then get the address indirectly?

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 ;-).

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