signal_receive.gen test fails on sparc #21

Whissi · 2018-01-02T12:30:39Z

A Gentoo sparc user (@DerDakon) is reporting the following reproducible test failure with strace-4.20:

FAIL: signal_receive.gen
========================

--- exp	2018-01-01 22:35:11.070789051 +0100
+++ log	2018-01-01 22:35:11.070789051 +0100
@@ -13,7 +13,7 @@
 kill(3066, SIGEMT) = 0
 --- SIGEMT {si_signo=SIGEMT, si_code=SI_USER, si_pid=3066, si_uid=250} ---
 kill(3066, SIGFPE) = 0
---- SIGFPE {si_signo=SIGFPE, si_code=SI_USER, si_pid=3066, si_uid=250} ---
+--- SIGFPE {si_signo=SIGFPE, si_code=SI_USER, si_pid=250, si_uid=0} ---
 kill(3066, SIGBUS) = 0
 --- SIGBUS {si_signo=SIGBUS, si_code=SI_USER, si_pid=3066, si_uid=250} ---
 kill(3066, SIGSEGV) = 0
signal_receive.gen.test: failed test: ../../strace -a16 -e trace=kill ../signal_receive output mismatch

His system's details:

Portage 2.3.13 (python 3.5.4-final-0, default/linux/sparc/17.0, gcc-6.4.0, glibc-2.25-r9, 4.14.8-gentoo-r1 sparc64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-4.14.8-gentoo-r1-sparc64-sun4v-with-gentoo-2.3
KiB Mem:    33133552 total,  19838904 free
KiB Swap:          0 total,         0 free
Timestamp of repository gentoo: Mon, 01 Jan 2018 01:15:01 +0000
Head commit of repository gentoo: 09c9b588c22ad79bf62481b1c30a40419f0429b7
sh bash 4.3_p48-r1
ld GNU ld (Gentoo 2.29.1 p3) 2.29.1
app-shells/bash:          4.3_p48-r1::gentoo
dev-lang/perl:            5.24.3::gentoo
dev-lang/python:          2.7.14-r1::gentoo, 3.4.5::gentoo, 3.5.4-r1::gentoo
dev-util/cmake:           3.9.6::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.3::gentoo
sys-apps/openrc:          0.34.11::gentoo
sys-apps/sandbox:         2.10-r4::gentoo
sys-devel/autoconf:       2.69::gentoo
sys-devel/automake:       1.15.1-r1::gentoo
sys-devel/binutils:       2.29.1-r1::gentoo
sys-devel/gcc:            6.4.0::gentoo
sys-devel/gcc-config:     1.8-r1::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1::gentoo
sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers)
sys-libs/glibc:           2.25-r9::gentoo

Build.log: https://bugs.gentoo.org/attachment.cgi?id=512660

Bug: https://bugs.gentoo.org/643060

The text was updated successfully, but these errors were encountered:

ldv-alt · 2018-01-02T16:09:51Z

What is a misterious process with pid==250 and uid==0, and why it sends signals instead of the process itself? It must be a problem in the operating system.

DerDakon · 2018-01-02T21:40:49Z

I suspect that either the the kernel fills the struct with wrong information, or strace wrongly interprets the struct layout. Any idea where to look?

Whissi · 2018-01-02T21:43:50Z

UID=250 is the user ("portage") building strace and running the test suite. So this could be an indicator that some struct information went bad...

ldv-alt · 2018-01-03T00:14:49Z

Looks like you build strace for 32-bit sparc. The last time I built strace this way was v4.16, the box where I could test this configuration (bender.sparc.dev.gentoo.org) is no longer accessible.

DerDakon · 2018-01-03T07:15:38Z

Send me patches ;)

ldv-alt · 2018-01-03T13:37:53Z

$ cat sigfpe.c
#include <assert.h>
#include <signal.h>
#include <stdio.h>
#include <unistd.h>

static void
handler(int sig, siginfo_t *info, void *ucontext)
{

fprintf(stderr, "sig=%d, si_signo=%d, si_pid=%d, si_uid=%d\n",
	sig, info->si_signo, info->si_pid, info->si_uid);

}

static void
setup(int sig, sigset_t *mask)
{

static const struct sigaction act = { .sa_sigaction = handler, .sa_flags = SA_SIGINFO };
assert(!sigaction(sig, &act, NULL));
assert(!sigaddset(mask, sig));

}

static void
test(int sig)
{

assert(!raise(sig));
assert(!kill(getpid(), sig));

}

int
main(void)
{

sigset_t mask;
assert(!sigemptyset(&mask));

setup(SIGFPE, &mask);
setup(SIGTERM, &mask);

assert(!sigprocmask(SIG_UNBLOCK, &mask, NULL));

test(SIGFPE);
test(SIGTERM);

return 0;

}

$ gcc -m32 -O2 sigfpe.c && ./a.out
sig=8, si_signo=8, si_pid=12345, si_uid=1000
sig=8, si_signo=8, si_pid=1000, si_uid=0
sig=15, si_signo=15, si_pid=12345, si_uid=1000
sig=15, si_signo=15, si_pid=12345, si_uid=1000

Could you make these buggy sparc kernels fixed, please?

jrtc27 · 2018-01-03T14:14:46Z

jrtc27@deb4g:~/tmp/sigfpe$ gcc -O2 sigfpe.c -o sigfpe64
jrtc27@deb4g:~/tmp/sigfpe$ ./sigfpe64
sig=8, si_signo=8, si_pid=135186, si_uid=1008
sig=8, si_signo=8, si_pid=135186, si_uid=1008
sig=15, si_signo=15, si_pid=135186, si_uid=1008
sig=15, si_signo=15, si_pid=135186, si_uid=1008
jrtc27@deb4g:~/tmp/sigfpe$ gcc -m32 -O2 sigfpe.c -o sigfpe32
jrtc27@deb4g:~/tmp/sigfpe$ ./sigfpe32
sig=8, si_signo=8, si_pid=135192, si_uid=1008
sig=8, si_signo=8, si_pid=1008, si_uid=0
sig=15, si_signo=15, si_pid=135192, si_uid=1008
sig=15, si_signo=15, si_pid=135192, si_uid=1008

ldv-alt · 2018-01-03T15:41:58Z

yes, sparc64 doesn't suffer from this, only sparc does.

DerDakon · 2018-01-03T20:28:51Z

Has this test been working before or is this a new test?

ldv-alt · 2018-01-03T20:51:06Z

The test used to pass on bender.sparc.dev.gentoo.org, "uname -a" used to print the following:
Linux bender 4.5.0 #4 SMP Thu Mar 24 18:28:58 UTC 2016 sparc64 sun4v UltraSparc T1 (Niagara) GNU/Linux

DerDakon · 2018-01-03T22:23:27Z

https://www.spinics.net/lists/sparclinux/msg19630.html

Recent kernel siginfo changes, namely, v4.14-rc1~60^2^2~1 and v4.16-rc1~159^2~10, introduced ABI regressions that render the whole siginfo interface unreliable. Looks like the kernel side is not eager to fix the breakage, so here is a workaround. * tests/signal_receive.c (s_sig, s_code, s_pid, s_uid): New volatile variables. (handler): Add siginfo_t parameter, save siginfo_t fields. (sig_print): Remove. (main): Rewrite. Use variables saved by handler to print expected siginfo output. Print diagnostics in case of siginfo mismatch. Closes: #21

Recent kernel siginfo changes, namely, v4.14-rc1~60^2^2~1 and v4.16-rc1~159^2~10, introduced ABI regressions that render the whole siginfo interface unreliable. Looks like the kernel side is not eager to fix the breakage, so here is a workaround. * tests/signal_receive.c (s_sig, s_code, s_pid, s_uid): New volatile variables. (handler): Add siginfo_t parameter, save siginfo_t fields. (sig_print): Remove. (main): Rewrite. Use variables saved by handler to print expected siginfo output. Print diagnostics in case of siginfo mismatch. * strace.spec.in (%check): Extract the diagnostics. Closes: #21

Starting with commit v4.14-rc1~60^2^2~1, a SIGFPE signal sent via kill results to wrong values in si_pid and si_uid fields of compat siginfo_t. This happens due to FPE_FIXME being defined to 0 for sparc, and at the same time siginfo_layout() introduced by the same commit returns SIL_FAULT for SIGFPE if si_code == SI_USER and FPE_FIXME is defined to 0. Fix this regression by removing FPE_FIXME macro and changing all its users to assign FPE_FLTUNK to si_code instead of FPE_FIXME. Note that FPE_FLTUNK is a new macro introduced by commit 266da65. Tested with commit v4.16-11958-g16e205cf42da. This bug was found by strace test suite. In the discussion about FPE_FLTUNK on sparc David Miller said: > Eric, feel free to do something similar on Sparc. Link: strace/strace#21 Fixes: cc73152 ("signal: Remove kernel interal si_code magic") Fixes: 2.3.41 Cc: David Miller <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Conceptually-Acked-By: David Miller <davem@davemloft.net> Thanks-to: Anatoly Pugachev <matorola@gmail.com> Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

Starting with commit v4.14-rc1~60^2^2~1, a SIGFPE signal sent via kill results to wrong values in si_pid and si_uid fields of compat siginfo_t. This happens due to FPE_FIXME being defined to 0 for sparc, and at the same time siginfo_layout() introduced by the same commit returns SIL_FAULT for SIGFPE if si_code == SI_USER and FPE_FIXME is defined to 0. Fix this regression by removing FPE_FIXME macro and changing all its users to assign FPE_FLTUNK to si_code instead of FPE_FIXME. Note that FPE_FLTUNK is a new macro introduced by commit 266da65. Tested with commit v4.16-11958-g16e205cf42da. This bug was found by strace test suite. Link: strace/strace#21 Fixes: cc73152 ("signal: Remove kernel interal si_code magic") Thanks-to: Anatoly Pugachev <matorola@gmail.com> Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: David S. Miller <davem@davemloft.net>

esyr added the external-bugs/kernel label Jan 30, 2018

ldv-alt closed this as completed in 34c7794 Apr 12, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

signal_receive.gen test fails on sparc #21

signal_receive.gen test fails on sparc #21

Whissi commented Jan 2, 2018

ldv-alt commented Jan 2, 2018

DerDakon commented Jan 2, 2018

Whissi commented Jan 2, 2018 •

edited

Loading

ldv-alt commented Jan 3, 2018

DerDakon commented Jan 3, 2018

ldv-alt commented Jan 3, 2018

jrtc27 commented Jan 3, 2018

ldv-alt commented Jan 3, 2018

DerDakon commented Jan 3, 2018

ldv-alt commented Jan 3, 2018 •

edited

Loading

DerDakon commented Jan 3, 2018 •

edited

Loading

signal_receive.gen test fails on sparc #21

signal_receive.gen test fails on sparc #21

Comments

Whissi commented Jan 2, 2018

ldv-alt commented Jan 2, 2018

DerDakon commented Jan 2, 2018

Whissi commented Jan 2, 2018 • edited Loading

ldv-alt commented Jan 3, 2018

DerDakon commented Jan 3, 2018

ldv-alt commented Jan 3, 2018

jrtc27 commented Jan 3, 2018

ldv-alt commented Jan 3, 2018

DerDakon commented Jan 3, 2018

ldv-alt commented Jan 3, 2018 • edited Loading

DerDakon commented Jan 3, 2018 • edited Loading

Whissi commented Jan 2, 2018 •

edited

Loading

ldv-alt commented Jan 3, 2018 •

edited

Loading

DerDakon commented Jan 3, 2018 •

edited

Loading