Re: [LTP] [PATCH] syscalls/waitid10: Fix on ARM, PPC and possibly others

[Cyril Hrubis <chrubis@suse.cz>]

Hi!
> >> While integer division by zero does trap on x86_64 and causes the SIGFPE
> >> signal to be delivered it's not the case on all architecutes. At least
> >> on ARM and PPC64LE division by zero simply returns undefined result
> >> instead.
> 
> Nit picking: even with this patch we are still testing undefined
> behaviour.
> 
>    There are six signals that can be delivered as a consequence of a
>    hardware exception: SIGBUS, SIGEMT, SIGFPE, SIGILL, SIGSEGV, and
>    SIGTRAP.  Which of these signals is delivered, for any given
>    hard- ware exception, is not documented and does not always make
>    sense.
> 
> If dividing by zero produces SIGEMT then it's still valid according to
> the specification. FPE does stand for floating point exception, but we
> are dividing integers.

Actually as far as I can tell the POSIX says that for integer division
by zero you shall get SIGFPE (and si_code in siginfo se tto FPE_INTDIV)
if the operation traps. It seems to be pretty well defined:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

> >> 
> >> This patch adds raise(SIGFPE) at the end of the child as a fallback to
> >> make sure the process is killed with the right signal on all
> >> architectures.
> >> 
> >> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> >> ---
> >>  testcases/kernel/syscalls/waitid/waitid10.c | 5 ++++-
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/testcases/kernel/syscalls/waitid/waitid10.c b/testcases/kernel/syscalls/waitid/waitid10.c
> >> index 869ef18bd..8c351d120 100644
> >> --- a/testcases/kernel/syscalls/waitid/waitid10.c
> >> +++ b/testcases/kernel/syscalls/waitid/waitid10.c
> >> @@ -28,7 +28,10 @@ static void run(void)
> >>  		volatile int a, zero = 0;
> >>  
> >>  		a = 1 / zero;
> >> -		exit(a);
> >> +
> >> +		tst_res(TINFO, "Division by zero didn't trap, raising SIGFPE");
> >
> > This patch inroduces 'set but not used' warning for the a variable so
> > maybe the message should look like:
> >
> > 		tst_res(TINFO, "1/0 = %i raising SIGFPE", a);
> >
> >> +		raise(SIGFPE);
> 
> I'm wondering if we should branch on the architecture. If it's x86[_64]
> then we only do divide by zero as it's reasonable to think that if the
> signal is not raised then this is a bug.

That would work too I guess.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp