Re: [patch V2 23/30] x86/fpu: Move fpregs_restore_userregs() to core
From: Borislav Petkov
Date: Tue Oct 19 2021 - 14:11:13 EST
On Fri, Oct 15, 2021 at 03:16:30AM +0200, Thomas Gleixner wrote:
> +static inline void fpregs_deactivate(struct fpu *fpu)
> +{
> + __this_cpu_write(fpu_fpregs_owner_ctx, NULL);
> + trace_x86_fpu_regs_deactivated(fpu);
> +}
> +
> +static inline void fpregs_activate(struct fpu *fpu)
> +{
> + __this_cpu_write(fpu_fpregs_owner_ctx, fpu);
> + trace_x86_fpu_regs_activated(fpu);
You're silently changing here the percpu writes to the __ variants and
AFAICT, there's no difference on x86:
# arch/x86/kernel/fpu/context.h:50: this_cpu_write(fpu_fpregs_owner_ctx, fpu);
#APP
# 50 "arch/x86/kernel/fpu/context.h" 1
movq %rsi, %gs:fpu_fpregs_owner_ctx(%rip) # fpu, fpu_fpregs_owner_ctx
# 0 "" 2
VS
# arch/x86/kernel/fpu/context.h:50: __this_cpu_write(fpu_fpregs_owner_ctx, fpu);
#APP
# 50 "arch/x86/kernel/fpu/context.h" 1
movq %rsi, %gs:fpu_fpregs_owner_ctx(%rip) # fpu, fpu_fpregs_owner_ctx
# 0 "" 2
except maybe the __ variant doesn't use the "volatile" inline asm
qualifier in the lower-level raw_cpu_write_8() vs this_cpu_write_8().
And there's the preemption check, ofc.
Or maybe this could have something to do with RT...?
Commit message could mention this change, though.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette