FPSCR and 64-bit signal handlers

[Gary Byers]

On Mon, 14 Nov 2005, Benjamin Herrenschmidt wrote:

>
>> 2) The assembly-language function flush_fp_to_thread() has a
>> side-effect on the f0/fr0 register (it's used to access the value of
>> the FPSCR and store it in the thread context after it and the other 31
>> fp registers have been saved there.)  There seem to be execution paths
>> in which flush_fp_to_thread() is called at least once between the time
>> that an exception is detected and the call above in setup_sigcontext()
>> (it's called in parse_fpe(), in .../arch/ppc64/traps.c); on any call
>> other than the first, the value of f0/fr0 saved in the current thread
>> context will be incorrect (it'll contain some of the bits that were in
>> the FPSCR on the most recent previous call.)  This means both that
>> signal handlers that care about the value of f0/fr0 will get incorrect
>> information and also that the value of f0/fr0 can change unexpectedly
>> on return from any signal handler whose context was established by
>> this function if there was more than one call to flush_fp_to_thread()
>> on the execution path.
>
> Have you seen any occurence of the above ? flush_fp_to_thread() called
> more than once should do nothing since the first call should clear the
> MSR_FP bit of the MSR copy in the thread structure, causing further
> calls to do nothing.

I must have been confused about this; I can't reproduce any case where
f0 gets clobbered as a result of calling flush_fp_to_thread() more than
once.

>
> Ben.
>
>
>