Timothy Pearson [off-list ref] writes:

...

So a little more detail on this, just to put it to rest properly vs.
assuming hand analysis caught every possible pathway. :)

The debugging that generates this stack trace also verifies the following in __giveup_fpu():

1.) tsk->thread.fp_state.fpr doesn't contain the FPSCR contents prior to calling save_fpu()
2.) tsk->thread.fp_state.fpr contains the FPSCR contents directly after calling save_fpu()
3.) MSR_FP is set both in the task struct and in the live MSR.

Only if all three conditions are met will it generate the trace.  This
is a generalization of the hack I used to find the problem in the
first place.

If the state will subsequently be reloaded from the thread struct,
that means we're reloading the registers from the thread struct that
we just verified was corrupted by the earlier save_fpu() call.  There
are only two ways I can see for that to be true -- one is if the
registers were already clobbered when giveup_all() was entered, and
the other is if save_fpu() went ahead and clobbered them right here
inside giveup_all().

To see which scenario we were dealing with, I added a bit more
instrumentation to dump the current register state if MSR_FP bit was
already set in registers (i.e. not dumping data from task struct, but
using the live FPU registers instead), and sure enough the registers
are corrupt on entry, so something else has already called save_fpu()
before we even hit giveup_all() in this call chain.

Can you share the debug patch you're using?

cheers