wait4 testcase for y2038 systems

[Dmitry V. Levin]

Hi,

On Fri, Mar 06, 2020 at 05:38:33PM -0800, Alistair Francis wrote:
> Hey,
> 
> I have a question.
> 
> Since the 5.1 kernel new 32-bit architectures (like RV32) don't have
> the wait4 kernel syscall as it isn't y2038 safe. Other 32-bit
> architectures will eventually also stop using the wait4 kernel syscall
> (by 2038 at least).
> 
> glibc still supports the wait4() function call, internally glibc will
> convert the programs wait4() call into waitid kernel calls.

glibc will support wait4() function call using __NR_wait4 at least until
the minimal Linux kernel version supported by glibc raises to 5.4, which
is not going to happen any time soon.

To be honest, I don't see any difference between __NR_wait4 and
__NR_waitid from y2038 perspective as both of them use the same
struct rusage.

> This means the strace wait4 testcase fails as it is run with these arguments:
>   strace -o log -e trace=wait4 -esignal=none ./wait4
> 
> The wait4 test case prints out wait4 calls, but the actual wait4
> function that is called doesn't do any wait4 kernel calls instead it
> does waitid kernel calls.
> 
> What would be the best way to handle this test for y2038 32-bit systems?

The main purpose of the strace test suite is to test strace.  Yes,
sometimes we discover bugs in other projects [1], but that's not the
purpose of the strace test suite.  A test of wait4 syscall decoder shall
invoke wait4 syscall.  If libc wait4() cannot be relied upon, the test
shall invoke __NR_wait4 syscall directly, like many other tests do when
they cannot use libc functions.  For example, tests/waitid.c invokes
__NR_waitid syscall directly because libc waitid() doesn't expose the 5th
argument.

[1] https://strace.io/wiki/TestSuiteBattlestars

-- 
ldv