summaryrefslogtreecommitdiffstats
path: root/Makefile
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2018-04-19 17:07:27 -0500
committerEric W. Biederman <ebiederm@xmission.com>2018-04-25 10:40:56 -0500
commitd8f7f3228a4b88d238d6a749e9a31eef37b270ea (patch)
tree65142c93ef21e97a23ff8281f261f68cf07d2e5e /Makefile
parentaeb1c0f6ff18f5ec1fe23421bd844d017bb364df (diff)
downloadlinux-d8f7f3228a4b88d238d6a749e9a31eef37b270ea.tar.bz2
signal/unicore32: Use FPE_FLTUNK instead of 0 in ucf64_raise_sigfpe
The si_code of 0 (aka SI_USER) has fields si_pid and si_uid not si_addr so it so only by luck would the appropriate fields by copied to userspace by copy_siginfo_to_user. This is just broken and wrong. Make it obvious what is happening by moving the si_code from a parameter of the one call to ucf64_raise_sigfpe to a constant value that info.si_code gets set to. Explicitly set the si_code to FPE_FLTUNK the newly reserved floating point si_code for an unknown floating point exception. It looks like there is a fair chance that this is a code path that has never been used in real life on unicore32. The bad si_code and the print statement that calls it an unhandled exception. So I really don't expect anyone will mind if this just gets fixed. In similar situations on more popular architectures the conclusion was just fix it. Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Cc: Arnd Bergmann <arnd@arndb.de> Fixes: d9bc15794d12 ("unicore32 additional architecture files: float point handling") Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions