[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3fe43c05-3505-498e-b36f-04da15f73b6b@linux.intel.com>
Date: Thu, 27 Jun 2024 11:50:55 +0800
From: "Ning, Hongyu" <hongyu.ning@...ux.intel.com>
To: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Cc: Andy Lutomirski <luto@...capital.net>,
Andrew Morton <akpm@...ux-foundation.org>, Dave Hansen <dave@...1.net>,
Peter Zijlstra <peterz@...radead.org>, Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>, Thomas Gleixner <tglx@...utronix.de>,
Uros Bizjak <ubizjak@...il.com>, kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH 3/3] x86/fpu: Remove init_task FPU state dependencies, add
debugging warning
On 2024/6/24 14:47, Ning, Hongyu wrote:
>
>
> On 2024/6/5 16:35, Ingo Molnar wrote:
>> init_task's FPU state initialization was a bit of a hack:
>>
>> __x86_init_fpu_begin = .;
>> . = __x86_init_fpu_begin + 128*PAGE_SIZE;
>> __x86_init_fpu_end = .;
>>
>> But the init task isn't supposed to be using the FPU in any case,
>> so remove the hack and add in some debug warnings.
>>
>> Signed-off-by: Ingo Molnar <mingo@...nel.org>
>> Cc: Andy Lutomirski <luto@...nel.org>
>> Cc: Borislav Petkov <bp@...en8.de>
>> Cc: Fenghua Yu <fenghua.yu@...el.com>
>> Cc: H. Peter Anvin <hpa@...or.com>
>> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
>> Cc: Oleg Nesterov <oleg@...hat.com>
>> Cc: Dave Hansen <dave.hansen@...ux.intel.com>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Cc: Uros Bizjak <ubizjak@...il.com>
>> Link: https://lore.kernel.org/r/ZgaNs1lC2Y+AnRG4@gmail.com
>> ---
>> arch/x86/include/asm/processor.h | 6 +++++-
>> arch/x86/kernel/fpu/core.c | 12 +++++++++---
>> arch/x86/kernel/fpu/init.c | 5 ++---
>> arch/x86/kernel/fpu/xstate.c | 3 ---
>> arch/x86/kernel/vmlinux.lds.S | 4 ----
>> 5 files changed, 16 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/processor.h
>> b/arch/x86/include/asm/processor.h
>> index 249c5fa20de4..ed8981866f4d 100644
>> --- a/arch/x86/include/asm/processor.h
>> +++ b/arch/x86/include/asm/processor.h
>> @@ -504,7 +504,11 @@ struct thread_struct {
>> #endif
>> };
>> -#define x86_task_fpu(task) ((struct fpu *)((void *)task +
>> sizeof(*task)))
>> +#ifdef CONFIG_X86_DEBUG_FPU
>> +extern struct fpu *x86_task_fpu(struct task_struct *task);
>> +#else
>> +# define x86_task_fpu(task) ((struct fpu *)((void *)task +
>> sizeof(*task)))
>> +#endif
>> /*
>> * X86 doesn't need any embedded-FPU-struct quirks:
>> diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
>> index 0ccabcd3bf62..fdc3b227800d 100644
>> --- a/arch/x86/kernel/fpu/core.c
>> +++ b/arch/x86/kernel/fpu/core.c
>> @@ -51,6 +51,15 @@ static DEFINE_PER_CPU(bool, in_kernel_fpu);
>> */
>> DEFINE_PER_CPU(struct fpu *, fpu_fpregs_owner_ctx);
>> +#ifdef CONFIG_X86_DEBUG_FPU
>> +struct fpu *x86_task_fpu(struct task_struct *task)
>> +{
>> + WARN_ON_ONCE(task == &init_task);
>> +
>> + return (void *)task + sizeof(*task);
>> +}
>> +#endif
>> +
>> /*
>> * Can we use the FPU in kernel mode with the
>> * whole "kernel_fpu_begin/end()" sequence?
>> @@ -591,10 +600,8 @@ int fpu_clone(struct task_struct *dst, unsigned
>> long clone_flags, bool minimal,
>> * This is safe because task_struct size is a multiple of
>> cacheline size.
>> */
>> struct fpu *dst_fpu = (void *)dst + sizeof(*dst);
>> - struct fpu *src_fpu = x86_task_fpu(current);
>> BUILD_BUG_ON(sizeof(*dst) % SMP_CACHE_BYTES != 0);
>> - BUG_ON(!src_fpu);
>> /* The new task's FPU state cannot be valid in the hardware. */
>> dst_fpu->last_cpu = -1;
>> @@ -657,7 +664,6 @@ int fpu_clone(struct task_struct *dst, unsigned
>> long clone_flags, bool minimal,
>> if (update_fpu_shstk(dst, ssp))
>> return 1;
>> - trace_x86_fpu_copy_src(src_fpu);
>> trace_x86_fpu_copy_dst(dst_fpu);
>> return 0;
>> diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
>> index 11aa31410df2..53580e59e5db 100644
>> --- a/arch/x86/kernel/fpu/init.c
>> +++ b/arch/x86/kernel/fpu/init.c
>> @@ -38,7 +38,7 @@ static void fpu__init_cpu_generic(void)
>> /* Flush out any pending x87 state: */
>> #ifdef CONFIG_MATH_EMULATION
>> if (!boot_cpu_has(X86_FEATURE_FPU))
>> - fpstate_init_soft(&x86_task_fpu(current)->fpstate->regs.soft);
>> + ;
>> else
>> #endif
>> asm volatile ("fninit");
>> @@ -164,7 +164,7 @@ static void __init fpu__init_task_struct_size(void)
>> * Subtract off the static size of the register state.
>> * It potentially has a bunch of padding.
>> */
>> - task_size -= sizeof(x86_task_fpu(current)->__fpstate.regs);
>> + task_size -= sizeof(union fpregs_state);
>> /*
>> * Add back the dynamically-calculated register state
>> @@ -209,7 +209,6 @@ static void __init
>> fpu__init_system_xstate_size_legacy(void)
>> fpu_kernel_cfg.default_size = size;
>> fpu_user_cfg.max_size = size;
>> fpu_user_cfg.default_size = size;
>> - fpstate_reset(x86_task_fpu(current));
>> }
>> /*
>> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
>> index 90b11671e943..1f37da22ddbe 100644
>> --- a/arch/x86/kernel/fpu/xstate.c
>> +++ b/arch/x86/kernel/fpu/xstate.c
>> @@ -844,9 +844,6 @@ void __init fpu__init_system_xstate(unsigned int
>> legacy_size)
>> if (err)
>> goto out_disable;
>> - /* Reset the state for the current task */
>> - fpstate_reset(x86_task_fpu(current));
>> -
>> /*
>> * Update info used for ptrace frames; use standard-format size
>> and no
>> * supervisor xstates:
>> diff --git a/arch/x86/kernel/vmlinux.lds.S
>> b/arch/x86/kernel/vmlinux.lds.S
>> index 226244a894da..3509afc6a672 100644
>> --- a/arch/x86/kernel/vmlinux.lds.S
>> +++ b/arch/x86/kernel/vmlinux.lds.S
>> @@ -170,10 +170,6 @@ SECTIONS
>> /* equivalent to task_pt_regs(&init_task) */
>> __top_init_kernel_stack = __end_init_stack -
>> TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE;
>> - __x86_init_fpu_begin = .;
>> - . = __x86_init_fpu_begin + 128*PAGE_SIZE;
>> - __x86_init_fpu_end = .;
>> -
>> #ifdef CONFIG_X86_32
>> /* 32 bit has nosave before _edata */
>> NOSAVE_DATA
>
> Hi,
>
> we've hit x86/fpu related WARNING and NULL pointer issue during KVM/QEMU
> VM booting with latest linux-next kernel, bisect results show it's
> related to this commit, would you take a look?
>
> detailed description in https://bugzilla.kernel.org/show_bug.cgi?id=218980
>
add a quick update:
1. CONFIG_X86_DEBUG_FPU=y was set by auto regression framework
2. disable CONFIG_X86_DEBUG_FPU will bypass above WARNING and NULL
pointer issue
it may not make sense for general kernel regression check to enable
CONFIG_X86_DEBUG_FPU=y, will revise auto regression framework to keep
CONFIG_X86_DEBUG_FPU disabled to bypass it.
in the meanwhile, please let me know if this issue is still valuable to
look into.
Powered by blists - more mailing lists