Re: AMD DC graphics display code enables -mhard-float, -msse, -msse2 without any visible FPU state protection

From: Christian KÃnig
Date: Thu Apr 02 2020 - 03:34:20 EST


Hi Jann,

Am 02.04.20 um 04:34 schrieb Jann Horn:
[x86 folks in CC so that they can chime in on the precise rules for this stuff]

Hi!

I noticed that several makefiles under drivers/gpu/drm/amd/display/dc/
turn on floating-point instructions in the compiler flags
(-mhard-float, -msse and -msse2) in order to make the "float" and
"double" types usable from C code without requiring helper functions.

However, as far as I know, code running in normal kernel context isn't
allowed to use floating-point registers without special protection
using helpers like kernel_fpu_begin() and kernel_fpu_end() (which also
require that the protected code never blocks). If you violate that
rule, that can lead to various issues - among other things, I think
the kernel will clobber userspace FPU register state, and I think the
kernel code can blow up if a context switch happens at the wrong time,
since in-kernel task switches don't preserve FPU state.

Is there some hidden trick I'm missing that makes it okay to use FPU
registers here?

I would try testing this, but unfortunately none of the AMD devices I
have here have the appropriate graphics hardware...

yes, using the floating point calculations in the display code has been a source of numerous problems and confusion in the past.

The calls to kernel_fpu_begin() and kernel_fpu_end() are hidden behind the DC_FP_START() and DC_FP_END() macros which are supposed to hide the architecture depend handling for x86 and PPC64.

This originated from the graphics block integrated into AMD CPU (where we knew which fp unit we had), but as far as I know is now also used for dedicated AMD GPUs as well.

I'm not really a fan of this either, but so far we weren't able to convince the hardware engineers to not use floating point calculations for the display stuff.

Regards,
Christian.