linux-kernel - Re: [patch 05/14] percpu: Use a Kconfig variable to configure arch specific percpu setup

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, 28 Nov 2007 16:11:37 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Rusty Russell <rusty@...tcorp.com.au>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...e.de>
Subject: Re: [patch 05/14] percpu: Use a Kconfig variable to configure arch
 specific percpu setup

On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:

 > Yes, I would like to convert x86_64 to match i386's percpu, and drop the
> pda altogether.  The only thing preventing this is the stack canary, and
> I'm wondering how much value there is in keeping it, given the
> disadvantages of having this divergence between 32 and 64 bit.

I think most of the PDA could be gotten rid of. The problems are

1. The stack canary

2. The PDA is used to store per cpu data before the per cpu areas
   are setup.

The i386 way of referring to per cpu data is not optimal because it is 
always offset by __per_cpu_start. per cpu data offsets need to be relative 
to the beginning of the per cpu area. per cpu data is less than 64k so 2 
byte offsets would be enough.

That way the __per_cpu_offset array and the registers that are used on 
various platforms are pointing to the actual data and can be loaded
directly into a register and then a load with a small offset to that 
register can be performed. On x86_64 this is gs, on i386 fs, on sparc g5, 
on ia64 a fixed address stands in for the register. In loops over all per 
cpu variables this will also simplify the code.

And ultimately we can get rid of the ugly RELOC_HIDE macro. It simply 
becomes the adding of the base address in a register to a per cpu offset.

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