Messages in this thread | | | Date | Fri, 17 Jul 2015 21:32:42 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |