RE: [PATCH v2] x86/fpu: Don't cache access to fpu_fpregs_owner_ctx
From: David Laight
Date: Fri Nov 29 2019 - 11:57:52 EST
From Sebastian Andrzej Siewior
> Sent: 28 November 2019 08:53
> The state/owner of FPU is saved fpu_fpregs_owner_ctx by pointing to the
> context that is currently loaded. It never changed during the life time
> of a task and remained stable/constant.
>
> Since deferred loading the FPU registers on return to userland, the
> content of fpu_fpregs_owner_ctx may change during preemption and must
> not be cached.
> This went unnoticed for some time and was now noticed, in particular
> gcc-9 is able to cache that load in copy_fpstate_to_sigframe() and reuse
> it in the retry loop:
>
> copy_fpstate_to_sigframe()
> load fpu_fpregs_owner_ctx and save on stack
> fpregs_lock()
> copy_fpregs_to_sigframe() /* failed */
> fpregs_unlock()
> *** PREEMPTION, another uses FPU, changes fpu_fpregs_owner_ctx ***
>
> fault_in_pages_writeable() /* succeed, retry */
>
> fpregs_lock()
> __fpregs_load_activate()
> fpregs_state_valid() /* uses fpu_fpregs_owner_ctx from stack */
> copy_fpregs_to_sigframe() /* succeeds, random FPU content */
Should both fpregs_lock() and fpregs_unlock() contain a barrier() (or "memory" clobber)
do stop the compiler moving anything across them?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)