From: Richard Palethorpe <rpalethorpe@suse.de>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] syscalls/waitid10: Fix on ARM, PPC and possibly others
Date: Mon, 21 Mar 2022 15:48:08 +0000 [thread overview]
Message-ID: <87ee2vclsf.fsf@suse.de> (raw)
In-Reply-To: <YinZzNWCiKalyWhd@yuki>
Hello,
Cyril Hrubis <chrubis@suse.cz> writes:
> 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.
>>
>> 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.
>> }
>>
>> TST_EXP_PASS(waitid(P_ALL, 0, infop, WEXITED));
>> --
>> 2.34.1
>>
>>
>> --
>> Mailing list info: https://lists.linux.it/listinfo/ltp
>
> --
> Cyril Hrubis
> chrubis@suse.cz
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-03-21 16:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 10:55 [LTP] [PATCH] syscalls/waitid10: Fix on ARM, PPC and possibly others Cyril Hrubis
2022-03-10 10:58 ` Cyril Hrubis
2022-03-21 15:48 ` Richard Palethorpe [this message]
2022-03-22 9:24 ` Cyril Hrubis
2022-03-30 13:29 ` Richard Palethorpe
2022-03-30 13:37 ` Martin Doucha
2022-03-31 10:07 ` Richard Palethorpe
2022-03-31 13:08 ` Cyril Hrubis
2022-04-19 8:07 ` Jan Stancek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ee2vclsf.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox