linux-kernel - Re: [PATCH 1/6] Initialize the per-CPU data area.

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:	Mon, 25 Sep 2006 14:33:27 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andi Kleen <ak@...e.de>
CC:	akpm@...l.org, linux-kernel@...r.kernel.org,
	Chuck Ebbert <76306.1226@...puserve.com>,
	Zachary Amsden <zach@...are.com>,
	Jan Beulich <jbeulich@...ell.com>,
	James Bottomley <James.Bottomley@...eleye.com>,
	Matt Tolentino <matthew.e.tolentino@...el.com>
Subject: Re: [PATCH 1/6] Initialize the per-CPU data area.

Andi Kleen wrote:
>> I'll respin it against your patches later today.
>>     
>
> Thanks. It's not that urgent because the merge will need a few days
> at least.
>   

I guess I should just use plain 2.6.19 as a base.

> Also I must admit I haven't figured out yet if yours or Rusty's patchkit
> is better. So far I was leaning towards yours, but that might be because
> I haven't looked closely at Rusty's version.

The basic machinery is similar, though he's gone and made things like 
the per-cpu GDTs actual percpu variables, with a bit of gymnastics to 
use them from assembler.  I haven't looked at the last iteration which 
does all the setup in the head.S assembler.

On the plus side, he makes some use of %gs to reference percpu data, and 
it's a nice simple patch to do so.  One slightly odd aspect of it is 
that %gs:0 is actually at a large offset below the percpu memory, in 
order to compensate for the offset of the percpu data section in the 
kernel address space.

And in my heart of hearts I'd prefer to use the compiler TLS support to 
do this; it gets better generated code (at least in the non-Xen case), 
with the downside of needing some more support in the module loader.  It 
also gets rid of all the special access macros/assembler for percpu 
variables.  (And ideally we can convince the gcc folks to allow 
generation of positive offset TLS relocations, and solve the Xen problem 
that way.)

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