OSDN Git Service

signal/unicore32: Use FPE_FLTUNK instead of 0 in ucf64_raise_sigfpe
authorEric W. Biederman <ebiederm@xmission.com>
Thu, 19 Apr 2018 22:07:27 +0000 (17:07 -0500)
committerEric W. Biederman <ebiederm@xmission.com>
Wed, 25 Apr 2018 15:40:56 +0000 (10:40 -0500)
commitd8f7f3228a4b88d238d6a749e9a31eef37b270ea
tree65142c93ef21e97a23ff8281f261f68cf07d2e5e
parentaeb1c0f6ff18f5ec1fe23421bd844d017bb364df
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>
arch/unicore32/kernel/fpu-ucf64.c