[PATCH v7 4/4] tests: check status qualifier

[Paul Chaignon]

On Wed, Jul 10, 2019 at 04:06:49AM +0300, Dmitry V. Levin wrote:

[...]

> After quit some time I managed to get the following:
> $ uname -a
> Linux lgentoo4 4.16.11 #1 SMP Fri May 25 06:41:48 EDT 2018 s390x 2964 IBM GNU/Linux
> $ ../strace -qfenanosleep ./status-none >/dev/null
> [pid 21584] nanosleep({tv_sec=123, tv_nsec=0}, NULL) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
> [pid 21584] syscall_0x3ff96e52800(0x3ffef1ff5e3, 0x3ff96d7efc8, 0, 0x3ff00000000, 0x3ff96d7f910, 0x3ffef1fea67) = 0x2d
> [pid 21584] syscall_0x24549000(0, 0x3ffee8ff038, 0x3ff926179bc, 0x1000c28, 0x3ff92625f98, 0x3ff92600ea0) = 0x5a
> [pid 21584] syscall_0x3ff9267c000(0x3ffee8fe748, 0x2000, 0x3, 0x22, 0xffffffffffffffff, 0x6) = 0x21
> [pid 21584] syscall_0xfffffffffffffffe(0x3ff9261e83e, 0x4, 0x6, 0x3ff92626000, 0x3ff9267e2e1, 0x3ff926270e0) = 0x120
> [pid 21584] syscall_0xfffffffffffff000(0x3, 0x3ffee8fdc20, 0x3ffee8fdc20, 0, 0, 0) = 0x5a
> [pid 21584] syscall_0x3ff92580000(0x3ffee8fdb48, 0x57c1, 0x1, 0x2, 0x3, 0) = 0x6
> [pid 21584] syscall_0xfffffffffffff000(0x3, 0x57c1, 0x1, 0x2, 0x3, 0) = 0x120
> [pid 21584] syscall_0x340(0x3, 0x3ffee8fdec0, 0x340, 0, 0, 0x3ff9267c7e0) = 0x6c
> [pid 21584] syscall_0x3ff926270a8(0x3, 0x3ffee8fdce8, 0x3ffee8fdce8, 0x3ffee8fdeb8, 0x3ff9267c7e0, 0x1) = 0x5a
> [pid 21584] syscall_0x3ff92500000(0x3ffee8fd9c0, 0x234c8, 0x5, 0x802, 0x3, 0x3ffee8fdad0) = 0x5a
> [pid 21584] syscall_0x3ff9251e000(0x3ffee8fd9c0, 0x2000, 0x3, 0x812, 0x3, 0x3ffee8fdad0) = 0x5a
> [pid 21584] syscall_0x3ff92520000(0x3ffee8fd9c0, 0x34c8, 0x3, 0x32, 0xffffffffffffffff, 0x3ffee8fdad0) = 0x6
> [pid 21584] syscall_0x340(0x3, 0x3ffee8fdea0, 0x340, 0, 0, 0x3ff9267ccd0) = 0x6c
> [pid 21584] syscall_0x3ff926270a8(0x3, 0x3ffee8fdcc8, 0x3ffee8fdcc8, 0x3ffee8fde98, 0x3ff9267ccd0, 0x1) = 0x5a
> [pid 21584] syscall_0x3ff92300000(0x3ffee8fd970, 0x1b5720, 0x5, 0x802, 0x3, 0x3ffee8fda80) = 0x5a
> [pid 21584] syscall_0x3ff924ac000(0x3ffee8fd970, 0x6000, 0x3, 0x812, 0x3, 0x3ffee8fda80) = 0x5a
> [pid 21584] syscall_0x3ff924b2000(0x3ffee8fd970, 0x3720, 0x3, 0x32, 0xffffffffffffffff, 0x3ffee8fda80) = 0x6
> [pid 21584] syscall_0x3ff924acde8(0x3, 0, 0x3ff92300290, 0x6fffffff, 0x6ffffeff, 0x6ffffdff) = 0x5a
> [pid 21584] syscall_0x3ff9267a000(0x3ffee8fe848, 0x2000, 0x3, 0x22, 0xffffffffffffffff, 0x3ff926270e0) = 0x7d
> [pid 21584] syscall_0x3ff924ac000(0x3ff924ac000, 0x4000, 0x1, 0x3ff924b0000, 0x3ff92300000, 0x3ff9267ccf0) = 0x7d
> [pid 21584] syscall_0x3ff9251e000(0x3ff9251e000, 0x1000, 0x1, 0x3ff9251f000, 0x3ff923988b0, 0x3ff9267c800) = 0x7d
> [pid 21584] syscall_0x1002000(0x1002000, 0x1000, 0x1, 0x1003000, 0, 0x3ff926270e0) = 0x7d
> [pid 21584] syscall_0x3ff92625000(0x3ff92625000, 0x1000, 0x1, 0x3ff92626000, 0x3ff92397ee8, 0x3ff92626988) = 0x5b
> [pid 21584] syscall_0x3ff9257ffff(0x3ff92580000, 0x57c1, 0x3ff926270e0, 0x3ff92626000, 0, 0x3ff926270e0) = 0xfc
> [pid 21584] syscall_0x5450(0x3ff9267a7f0, 0x3ffee8feef8, 0x3ff9267a720, 0x3ffee8fef10, 0x3ffee8fef10, 0x3ffee8fef10) = 0x130
> [pid 21584] syscall_0x3ff9267a720(0x1, 0x3ffee8febe8, 0, 0x8, 0x3ffee8fef10, 0x3ffee8fef10) = 0x14e
> [pid 21584] syscall_0x5450(0, 0x3ff9267a720, 0x1000b5c, 0x3ff924acec8, 0x1001150, 0x3ffee8feee0) = 0x4
> [pid 21584] syscall_0x1c(0x1, 0x3ffee8fc510, 0x1c, 0x3ff924b56a0, 0x3ff924acec8, 0x1c) = 0xf8
> [pid 21584] +++ exited with 0 +++
> ../strace: wait4(__WALL): No child processes
>
> This was the version of status-none with clock_nanosleep and without
> nanosleep in thread().  There was no "Stray PTRACE_EVENT_EXEC" message
> and strace apparently got confused between syscall entering and exiting.

I'm not quite sure what to make of this.  Do you think this is a bug
introduced by this patchset?  I have seen such bugs (syscall entry/exit
confusion) with the seccomp patchset, but never with this one.  Do you
have a way to reproduce?

Paul