• Linus Torvalds's avatar
    i387: move TS_USEDFPU flag from thread_info to task_struct · f94edacf
    Linus Torvalds authored
    This moves the bit that indicates whether a thread has ownership of the
    FPU from the TS_USEDFPU bit in thread_info->status to a word of its own
    (called 'has_fpu') in task_struct->thread.has_fpu.
    
    This fixes two independent bugs at the same time:
    
     - changing 'thread_info->status' from the scheduler causes nasty
       problems for the other users of that variable, since it is defined to
       be thread-synchronous (that's what the "TS_" part of the naming was
       supposed to indicate).
    
       So perfectly valid code could (and did) do
    
    	ti->status |= TS_RESTORE_SIGMASK;
    
       and the compiler was free to do that as separate load, or and store
       instructions.  Which can cause problems with preemption, since a task
       switch could happen in between, and change the TS_USEDFPU bit. The
       change to TS_USEDFPU would be overwritten by the final store.
    
       In practice, this seldom happened, though, because the 'status' field
       was seldom used more than once, so gcc would generally tend to
       generate code that used a read-modify-write instruction and thus
       happened to avoid this problem - RMW instructions are naturally low
       fat and preemption-safe.
    
     - On x86-32, the current_thread_info() pointer would, during interrupts
       and softirqs, point to a *copy* of the real thread_info, because
       x86-32 uses %esp to calculate the thread_info address, and thus the
       separate irq (and softirq) stacks would cause these kinds of odd
       thread_info copy aliases.
    
       This is normally not a problem, since interrupts aren't supposed to
       look at thread information anyway (what thread is running at
       interrupt time really isn't very well-defined), but it confused the
       heck out of irq_fpu_usable() and the code that tried to squirrel
       away the FPU state.
    
       (It also caused untold confusion for us poor kernel developers).
    
    It also turns out that using 'task_struct' is actually much more natural
    for most of the call sites that care about the FPU state, since they
    tend to work with the task struct for other reasons anyway (ie
    scheduling).  And the FPU data that we are going to save/restore is
    found there too.
    
    Thanks to Arjan Van De Ven <arjan@linux.intel.com> for pointing us to
    the %esp issue.
    
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Reported-and-tested-by: default avatarRaphael Prevost <raphael@buro.asia>
    Acked-and-tested-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
    Tested-by: default avatarPeter Anvin <hpa@zytor.com>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    f94edacf
vmx.c 206 KB