linux-kernel - Re: [RFC 00/15] x86_64: Optimize percpu accesses

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: <20080709200057.GA14009@elte.hu>
Date:	Wed, 9 Jul 2008 22:00:57 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Mike Travis <travis@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"H. Peter Anvin" <hpa@...or.com>, Jack Steiner <steiner@....com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC 00/15] x86_64: Optimize percpu accesses

* Christoph Lameter <cl@...ux-foundation.org> wrote:

> Ingo Molnar wrote:
> 
> > that makes sense. Does everyone agree on #1-#2-#3 and then gradual 
> > elimination of most pda members (without going through an 
> > intermediate renaming of pda members) being the way to go?
> 
> I think we all agree on 1-2-3.
> 
> The rest is TBD. Hope Jeremy can add his wisdom there to get the pda.X 
> replaced by the proper percpu names for 32 bit.
> 
> With Jeremy's approach we would be doing two steps at once (getting 
> rid of pda ops plus unifying the variable names between 32 and 64 
> bit). Maybe more difficult to verify correctness. The removal of the 
> pda ops is a pretty straighforward conversion.

Yes, but there's nothing magic about pda variables versus percpu 
variables. We should be able to do the pda -> unified step just as much 
as we can do a percpu -> unified step. We can think of pda as a funky, 
pre-percpu-era relic.

The only thing that percpu really offers over pda is its familarity. 
read_pda() has the per-cpu-ness embedded in it, which is nasty with 
regard to tracking preemption properties, etc.

So converting to percpu would bring us CONFIG_PREEMPT_DEBUG=y checking 
to those ex-pda variables. Today if a read_pda() (or anything but 
pcurrent) is done in a non-preempt region that's likely a bug - but 
nothing warns about it.

So in that light 4-15 might make some sense in standardizing all these 
accesses and making sure it all fits into an existing, familar API 
world, with no register level assumptions and assembly (and ABI) ties, 
which is instrumented as well, with explicit smp_processor_id() 
dependencies, etc.

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