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

[Paul Chaignon]

On Wed, Jul 10, 2019 at 05:04:33PM +0300, Dmitry V. Levin wrote:
> On Wed, Jul 10, 2019 at 03:52:46PM +0200, Paul Chaignon wrote:
> > 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?
> 
> No, I'm pretty sure it can be reproduced without this patchset, too.
> 
> > 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?
> 
> I had to run the test in a loop on that s390x box for quite some time,
> and 1 of 25756 iterations ended up with that mess, that's all I know.
> 
> I couldn't reproduce this on x86_64 or ppc64le, though.

With all this, we're going to have a hard time checking that the
status-unfinished test doesn't return anything inappropriate...  Since we
now also have a single-thread test for status=unfinished, couldn't we just
run the current status-unfinished test in a loop until it returns the
expected output, without checking for inappropriate outputs?

Paul