| Date | Tue, 19 Oct 2021 20:11:07 +0200 | From | Borislav Petkov <> | Subject | Re: [patch V2 23/30] x86/fpu: Move fpregs_restore_userregs() to core |
| |
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
|