lkml.org 
[lkml]   [2015]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [REGRESSION] 4.2-rc2: early boot memory corruption from FPU rework

    * Dave Hansen <dave.hansen@linux.intel.com> wrote:

    > On 07/17/2015 12:45 AM, Ingo Molnar wrote:
    > > Just curious: does any released hardware have AVX-512? I went by Wikipedia, which
    > > seems to list pre-release hw:
    >
    >
    > >> We might know the size and composition of the individual components, but we do
    > >> not know the size of the buffer. Different implementations of a given feature
    > >> are quite free to have different data stored in the buffer, or even to rearrange
    > >> or pad it. That's why the sizes are not explicitly called out by the
    > >> architecture and why we enumerated them before your patch that caused this
    > >> regression.
    > >
    > > But we _have_ to know their structure and layout of the XSAVE context for any
    > > reasonable ptrace and signal frame support.
    >
    > There are two different things here. One is the structure and layout inside of
    > the state components. That obviously needs full kernel knowledge and can not be
    > opaque, especially when the kernel needs to go looking at it (like with MPX's
    > BNDCSR for instance).
    >
    > But, the relative layout of the components is up for grabs. The CPU is
    > completely free (architecturally) to pad components or rearrange things.
    >
    > It's not opaque (it's fully enumerated in CPUID), but it's far from something
    > which is static or which we can realistically represent in a static structure.

    Ok, agreed.

    > > Can you set/get AVX-512 registers via ptrace? MPX state?
    >
    > The xsave buffer is just copied out to userspace with REGSET_XSTATE. Userspace
    > needs to do the same song and dance with CPUID to parse it that the kernel does.

    Indeed - I missed REGSET_XSTATE and its interaction with
    update_regset_xstate_info().

    Good - I have no other complaints.

    > > This needs some (very minor) changes to kernel/fork.c to allow an architecture
    > > to determine the full task_struct size dynamically - but looks very doable and
    > > clean. Wanna try this, or should I?
    >
    > I think you already did this later in the thread.

    Yeah, wanted to get a fix for the regression to Linus ASAP. If we go changing core
    code in kernel/fork.c we better have it in -rc3.

    So right now I have these two applied:

    0f6df268588f x86/fpu, sched: Dynamically allocate 'struct fpu'
    218d096a24b4 x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86

    ... do we need any of the other patches you sent to get working AVX512 support?
    I think we should be fine, but I don't have the hardware.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2015-07-17 22:01    [W:2.877 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site