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:	Wed, 1 Apr 2009 10:01:17 +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 17:10:40 -0400 (EDT)
Christoph Lameter <cl@...ux.com> wrote:

> On Tue, 31 Mar 2009, Martin Schwidefsky wrote:
> 
> > > 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?
> 
> The patch needs to show up when I press reply and not vanish. I guess this
> was an attachment.

Hmm, interesting. The patch was part of the message body but came after
the signature. I'll make the signature the last thing in my mails in the
future.

> > I don't see how changes to the initial per cpu segment should help with
> > access to per cpu symbols.
> 
> Can you convince the linker to place the per cpu segment > 4G away from
> the code? Its a virtual address right?

Yes it is a virtual address but the linker has nothing to do with it.
It is the compiler that makes the assumption that an static variable
can be accessed within < 4G. The module loader then rips the code and
the .data.percpu section apart and places them at memory locations
which are farther away than 4GB.

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