lkml.org 
[lkml]   [2019]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH v2] x86/fpu: Don't cache access to fpu_fpregs_owner_ctx
    Date
    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)
    \
     
     \ /
      Last update: 2019-11-29 17:59    [W:2.809 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site