lkml.org 
[lkml]   [2018]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v2 7/8] x86/segments/32: Introduce CPU_NUMBER segment
    On Wed, Jun 6, 2018 at 9:23 AM Chang S. Bae <chang.seok.bae@intel.com> wrote:
    >
    > The new entry will be equivalent to that of x86-64 which
    > stores CPU number. The entry is placed in segment 23 in GDT
    > by bumping down 23-28 by one, which are all kernel-internal
    > segments and so have no impact on user space.
    >
    > CPU_NUMBER segment will always be at '%ss (USER_DS) + 80'
    > for the default (flat, initial) user space %ss.

    No, it won't :( This is because, on Xen PV, user code very frequently
    sees a different, Xen-supplied "flat" SS value. This is definitely
    true right now on 64-bit, and I'm reasonably confident it's also the
    case on 32-bit.

    As it stands, as far as I can tell, we don't have a "cpu number"
    segment on 32-bit kernels. I see no compelling reason to add one, and
    we should definitely not add one as part of the FSGSBASE series. I
    think the right solution is to rename the 64-bit segment to
    "CPU_NUMBER" and then have the rearrangement of the initialization
    code as a followup patch. The goal is to make the patches
    individually reviewable. As it stands, this patch adds some #defines
    without making them work, which is extra confusing.

    Given how many times we screwed it up, I really want the patch that
    moves the initialization of the 64-bit CPU number to be obviously
    correct and to avoid changing the sematics of anything except the
    actual CPU number fields during boot.

    So NAK to this patch, at least as part of the FSGSBASE series.

    (My apologies -- a bunch of this is because I along with everyone else
    misunderstood the existing code.)

    \
     
     \ /
      Last update: 2018-06-06 19:17    [W:8.134 / U:0.620 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site