Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH v2] x86/fpu: Don't cache access to fpu_fpregs_owner_ctx | Date | Fri, 29 Nov 2019 16:57:42 +0000 |
| |
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)
| |