LKML Archive on
help / color / mirror / Atom feed
From: "H. Peter Anvin" <>
To: "Mika Penttilä" <>,
	"Chang S. Bae" <>,
	"Andy Lutomirski" <>,
	"Thomas Gleixner" <>,
	"Ingo Molnar" <>
Cc: Andi Kleen <>,
	Dave Hansen <>,
	Markus T Metzger <>,
	"Ravi V . Shankar" <>,
	LKML <>
Subject: Re: [PATCH 6/6] x86/vdso: Move out the CPU number store
Date: Mon, 4 Jun 2018 22:36:27 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 06/04/18 20:57, Mika Penttilä wrote:
> This won't work on X86-32 because it actually uses the segment limit with fs: access. So there 
> is a reason why the lsl based method is X86-64 only.

<thinks out loud>

Why does that matter in any shape, way, or form?  The LSL instruction
doesn't touch any of the segment registers, it just uses a segment
selector number.

<looks at code>

I see... we have a VERY unfortunate name collision: the x86-64
GDT_ENTRY_PERC_PU and the i386 GDT_ENTRY_PERCPU are in fact two
completely different things, with the latter being the actual percpu
offset used by the kernel.

So yes, this patch is wrong, because the naming of the x86-64 segment is
insane especially in the proximity of the  -- it should be something

Unfortunately we probably can't use the same GDT entry on x86-32 and
x86-64, because entry 15 (selector 0x7b) is USER_DS, which is something
we really don't want to screw with.  This means i386 programs that
execute LSL directly for whatever reason will have to understand the
difference, but most of the other segment numbers differ as well,
including user space %cs (USER_CS/USER32_CS) and %ds/%es/%ss (USER_DS).
Perhaps we could bump down segments 23-28 by one and put it as 23, that
way the CPU_NUMBER segment would always be at %ss+80 for the default
(flat, initial) user space %ss.  (We want to specify using %ss rather
than %ds, because it is less likely to be changed and because 64 bits,
too, have %ss defined, but not %ds.)

<action item>

Rename the x86-64 segment to CPU_NUMBER, fixing the naming conflict.
Add 1 to GDT entry numbers 23-28 for i386 (all of these are
kernel-internal segments and so have no impact on user space).
Add i386 CPU_NUMBER equivalent to x86-64 at GDT entry 23.
Document the above relationship between segments.

OK, everyone?


  parent reply	other threads:[~2018-06-05  5:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-04 19:24 [PATCH 0/6] x86: infrastructure to enable FSGSBASE Chang S. Bae
2018-06-04 19:24 ` [PATCH 1/6] x86/fsgsbase/64: Introduce FS/GS base helper functions Chang S. Bae
2018-06-04 19:24 ` [PATCH 2/6] x86/fsgsbase/64: Make ptrace read FS/GS base accurately Chang S. Bae
2018-06-04 19:24 ` [PATCH 3/6] x86/fsgsbase/64: Use FS/GS base helpers in core dump Chang S. Bae
2018-06-04 19:24 ` [PATCH 4/6] x86/fsgsbase/64: Factor out load FS/GS segments from __switch_to Chang S. Bae
2018-06-04 19:24 ` [PATCH 5/6] x86/msr: write_rdtscp_aux() to use wrmsr_safe() Chang S. Bae
2018-06-04 19:24 ` [PATCH 6/6] x86/vdso: Move out the CPU number store Chang S. Bae
2018-06-05  3:57   ` Mika Penttilä
2018-06-05  4:44     ` Bae, Chang Seok
2018-06-05  5:19       ` Mika Penttilä
2018-06-05  5:36     ` H. Peter Anvin [this message]
2018-06-05  6:03       ` Mika Penttilä
2018-06-05 10:22       ` Andy Lutomirski
2018-06-13  6:53   ` [lkp-robot] [x86/vdso] ab1bcc4420: BUG:kernel_hang_in_boot_stage kernel test robot

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 6/6] x86/vdso: Move out the CPU number store' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).