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]

Date:	Tue, 31 Mar 2009 22:18:47 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Tejun Heo <tj@...nel.org>, 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 Tue, 31 Mar 2009 13:20:42 -0400 (EDT)
Christoph Lameter <cl@...ux.com> wrote:

> On Tue, 31 Mar 2009, Martin Schwidefsky wrote:
> 
> > I got the dynamic cpu allocator to work with the patch below. Anybody
> > with an objection against the SHIFT_PERCPU_VAR macro ?
> 
> Please include the patch inline next time.

What do you mean by "inline"? That the patch should not be the last
thing in the mail?

> Why is there a difference between percpu alloc and "static" percpu
> variables? The "static" percpu variables can be dynamically allocated when
> a module is loaded.

We need to hide the static per cpu symbol from the compiler, otherwise
the compiler will try to load the address of the symbol with an
instruction that is limited in the addressing range of a single elf
object. We do that will the inline assembly in SHIFT_PERCPU_PTR

#define SHIFT_PERCPU_PTR(ptr,offset) (({                \
        extern int simple_identifier_##var(void);       \
        unsigned long *__ptr;                           \
        asm ( "larl %0, %1@...ENT"                      \
            : "=a" (__ptr) : "X" (ptr) );               \
        (typeof(ptr))((*__ptr) + (offset));     }))

The "X" constraint only works if ptr is the name of a symbol. The
per_cpu_ptr macro will use SHIFT_PERCPU_PTR on an pointer which does
not compile. For pointers we do not need to trick the compiler, we can
just use the standard RELOC_HIDE.

> Isnt this mmore an issue that can be addressed by changing the way the initial per cpu
> segment is allocated? If its also dynamically allocated then there should
> be no problem?
 
I don't see how changes to the initial per cpu segment should help with
access to per cpu symbols.

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