On 01/29, Rik van Riel wrote: > > On 01/29/2015 04:08 PM, Oleg Nesterov wrote: > > unlazy_fpu()->__thread_fpu_end() doesn't look right if use_eager_fpu(). > > Unconditional __thread_fpu_end() is only correct if we know that this > > thread can't return to user-mode and use FPU. > > > > Fortunately it has only 2 callers. fpu_copy() checks use_eager_fpu(), > > and init_fpu(current) can be only called by the coredumping thread via > > regset->get(). But it is exported to modules, and imo this should be > > fixed anyway. > > What about xfpregs_set? > > It looks like that code copies an entire FPU state in > from userspace, and expects the kernel to start using > that new FPU state. > > This is called from the ptrace code.
Yes. But in this case tsk != current, and we ensure that __switch_to() was finished. wait_task_inactive(). > When we switch to the traced task, the __thread_fpu_end() > that was called from init_fpu() ensures that > switch_fpu_begin() will actually load the new FPU state > from memory into the registers, and we will not take > the fpu_lazy_restore() branch. No. in this case we rely on "tsk->thread.fpu.last_cpu = ~0" which disables fpu_lazy_restore(). > What am I missing? Or me ;) Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
