[PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE
Maciej W. Rozycki
macro at imgtec.com
Tue Aug 8 23:19:12 UTC 2017
On Tue, 8 Aug 2017, Eric W. Biederman wrote:
> > This is an "impossible" state to reach unless your hardware is on fire.
> > One or more of the FCSR Cause bits will have been set (in `fcr31') or the
> > FPE exception would not have happened.
> > Of course there could be a simulator bug, or we could have breakage
> > somewhere causing `process_fpemu_return' to be called with SIGFPE and
> > inconsistent `fcr31'. So we need to handle it somehow.
> > So what would be the right value of `si_code' to use here for such an
> > unexpected exception condition? I think `BUG()' would be too big a
> > hammer here. Or wouldn't it?
> The possible solutions I can think of are:
> WARN_ON_ONCE with a comment.
> Add a new si_code to uapi/asm-generic/siginfo.h perhaps FPE_IMPOSSIBLE.
> Like syscall numbers si_codes are cheap.
I think we ought to do both.
First, we have our own FP emulation code, which is changed from time to
time, that uses the same exit path that the hardware exception does. It
could happen that we miss something and return SIGFPE from the emulation
code without setting the cause bits appropriately. This would be our own
bug which might trigger exceedingly rarely and could then be caught by
WARN_ON_ONCE or otherwise stay there forever in the absence of that check.
Second, changing `si_code' from __SI_FAULT to 0 aka __SI_KILL will likely
interfere with `copy_siginfo_to_user32' in arch/mips/kernel/signal32.c,
making the userland lose the address of the faulting instruction in 32-bit
software run on 64-bit hardware only, making our API inconsistent. Using
a distinct `si_code' value such as FPE_IMPOSSIBLE (though we might choose
say FPE_FLTUNK for "FLoaTing point UNKnown" instead, for consistency; mind
that most `si_code' macros have the same number of characters within
groups associated with individual signals) for such odd traps is allowed
by SUS and will prevent the inconsistency from happening, very cheaply as
More information about the Containers