From: Rusty Russell <rusty@rustcorp.com.au>
To: Christoph Lameter <clameter@sgi.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
Andi Kleen <ak@suse.de>, Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [patch 05/14] percpu: Use a Kconfig variable to configure arch specific percpu setup
Date: Thu, 29 Nov 2007 10:17:52 +1100 [thread overview]
Message-ID: <200711291017.52727.rusty@rustcorp.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0711281050470.11968@schroedinger.engr.sgi.com>
On Thursday 29 November 2007 05:51:29 Christoph Lameter wrote:
> On Wed, 28 Nov 2007, Rusty Russell wrote:
> > On Wednesday 28 November 2007 05:14:47 Christoph Lameter wrote:
> > > On Tue, 27 Nov 2007, Rusty Russell wrote:
> > > > Have you considered moving x86-64's setup_per_cpu_areas into generic
> > > > code? It's a bit messier because some archs might not have set up
> > > > NUMA stuff yet, but it's logically generic...
> > >
> > > Yes that will happen later. This is just the early cleanup work. I
> > > plan to generally bring the two x86 arches in line. The pda will be
> > > folded into the per cpu area and after that its easy to do.
> >
> > Unfortunately, we tried to get rid of the x86-64 pda (like i386) but you
> > lose the ability to use the stack protection config option. That's
> > because it assumes that gs:0x68 (or something) is the stack canary; we
> > need a YA gcc change to make this gs:__builtin_stack_canary_off (where
> > gcc can emit __builtin_stack_canary_off as a weak absolute symbol, so we
> > can override it for the kernel.
>
> This works if you rebase the per cpu area at zero. gs:0x68 is still the
> stack canary.
>
> The i386 method does not work because the segment register does not
> directly point to the pda.
But the PDA itself is silly (Jeremy ported it to i386 and I balked). We have
a generic one: it's called the per-cpu data. Having a completely separate
per-cpu structure for x86-64 is a mistake.
Setting up gs as the per-cpu offset has lovely properties and avoids YA
arch-specific concept; see the i386 code. Introducing a generic
read_percpu()/write_percpu() would even make it optimal.
Cheers,
Rusty.
next prev parent reply other threads:[~2007-11-28 23:18 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-27 0:14 [patch 00/14] Per cpu code simplification Christoph Lameter
2007-11-27 0:14 ` [patch 01/14] Modules: Handle symbols that have a zero value Christoph Lameter
2007-11-27 0:14 ` [patch 02/14] Modules: Include sections.h to avoid defining linker variables explicitly Christoph Lameter
2007-11-27 0:14 ` [patch 03/14] Modules: Fold percpu_modcopy into module.c and get rid of the macro from hell Christoph Lameter
2007-11-27 0:14 ` [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access Christoph Lameter
2007-11-27 5:20 ` David Mosberger-Tang
2007-11-27 18:15 ` Christoph Lameter
2007-11-27 21:10 ` David Mosberger-Tang
2007-11-27 21:18 ` Christoph Lameter
2007-11-27 21:27 ` David Mosberger-Tang
2007-11-27 22:02 ` Christoph Lameter
2007-11-27 9:30 ` Andreas Schwab
2007-11-27 18:17 ` Christoph Lameter
2007-11-27 21:24 ` Andreas Schwab
2007-11-27 21:38 ` Christoph Lameter
2007-11-27 22:14 ` Adrian Bunk
2007-11-27 0:14 ` [patch 05/14] percpu: Use a Kconfig variable to configure arch specific percpu setup Christoph Lameter
2007-11-27 4:30 ` Rusty Russell
2007-11-27 18:14 ` Christoph Lameter
2007-11-28 1:36 ` Rusty Russell
2007-11-28 18:51 ` Christoph Lameter
2007-11-28 23:17 ` Rusty Russell [this message]
2007-11-28 23:36 ` Christoph Lameter
2007-11-30 2:23 ` Rusty Russell
2007-11-28 23:45 ` Jeremy Fitzhardinge
2007-11-29 0:11 ` Christoph Lameter
2007-11-29 1:18 ` Andi Kleen
2007-11-29 1:27 ` Christoph Lameter
2007-11-29 1:30 ` Jeremy Fitzhardinge
2007-11-29 1:32 ` Andi Kleen
2007-11-29 1:35 ` Christoph Lameter
2007-11-29 1:42 ` Jeremy Fitzhardinge
2007-11-29 1:48 ` Christoph Lameter
2007-11-29 1:54 ` Jeremy Fitzhardinge
2007-11-29 2:06 ` Christoph Lameter
2007-11-29 5:29 ` Jeremy Fitzhardinge
2007-11-29 6:08 ` Christoph Lameter
2007-11-29 6:10 ` Christoph Lameter
2007-11-27 23:40 ` Randy Dunlap
2007-11-28 0:03 ` Christoph Lameter
2007-11-28 0:05 ` Randy Dunlap
2007-11-27 0:14 ` [patch 06/14] percpu: Move arch XX_PER_CPU_XX definitions into linux/percpu.h Christoph Lameter
2007-11-27 0:14 ` [patch 07/14] percpu: Make the asm-generic/percpu.h more generic Christoph Lameter
2007-11-27 0:14 ` [patch 08/14] x86_32: Use generic percpu.h Christoph Lameter
2007-11-27 0:14 ` [patch 09/14] x86_64: Use generic percpu Christoph Lameter
2007-11-27 0:14 ` [patch 10/14] s390: " Christoph Lameter
2007-11-27 0:14 ` [patch 11/14] Powerpc: Use generic per cpu Christoph Lameter
2007-11-27 7:41 ` Kumar Gala
2007-11-27 18:16 ` Christoph Lameter
2007-11-27 20:58 ` Paul Mackerras
2007-11-27 21:13 ` Christoph Lameter
2007-11-28 2:35 ` Paul Mackerras
2007-11-28 18:54 ` Christoph Lameter
2007-12-02 20:55 ` Benjamin Herrenschmidt
2007-11-27 0:14 ` [patch 12/14] Sparc64: Use generic percpu Christoph Lameter
2007-11-27 0:14 ` [patch 13/14] ia64: " Christoph Lameter
2007-11-27 1:37 ` Christoph Lameter
2007-11-27 0:14 ` [patch 14/14] x86: Unify percpu.h Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200711291017.52727.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).