getitimer01 in ubuntu_ltp_syscalls failed with X-aws

[Po-Hsu Lin]

Issue found with X-aws 4.4.0-1158.173

This is not a regression but caused by a test case update in https://github.com/linux-test-project/ltp/commit/a86c775eb6fa50ba6a3570607959de95ffb1aa72

This can be reproduced with 4.4.0-1153.168 (which has passed with an older version of LTP)

Test failed with:
INFO: Test start time: Tue Jul 4 15:43:36 UTC 2023
COMMAND: /opt/ltp/bin/ltp-pan -q -e -S -a 7283 -n 7283 -f /tmp/ltp-zivcDAGgp0/alltests -l /dev/null -C /dev/null -T /dev/null
LOG File: /dev/null
FAILED COMMAND File: /dev/null
TCONF COMMAND File: /dev/null
Running tests.......
tst_buffers.c:55: TINFO: Test is using guarded buffers
tst_test.c:1560: TINFO: Timeout per run is 0h 00m 30s
getitimer01.c:45: TINFO: tc->which = ITIMER_REAL
getitimer01.c:51: TINFO: Test begin time: 1688485416.75635s
getitimer01.c:54: TPASS: getitimer(tc->which, value) passed
getitimer01.c:55: TPASS: value->it_value.tv_sec == 0 (0)
getitimer01.c:56: TPASS: value->it_value.tv_usec == 0 (0)
getitimer01.c:57: TPASS: value->it_interval.tv_sec == 0 (0)
getitimer01.c:58: TPASS: value->it_interval.tv_usec == 0 (0)
getitimer01.c:61: TPASS: setitimer(tc->which, value, NULL) passed
getitimer01.c:64: TPASS: getitimer(tc->which, value) passed
getitimer01.c:66: TPASS: value->it_interval.tv_sec == SEC (100)
getitimer01.c:67: TPASS: value->it_interval.tv_usec == USEC (10000)
getitimer01.c:70: TINFO: value->it_value.tv_sec=100, value->it_value.tv_usec=9997
getitimer01.c:91: TPASS: timer value is within the expected range
getitimer01.c:97: TINFO: Test end time: 1688485416.75676s
getitimer01.c:45: TINFO: tc->which = ITIMER_VIRTUAL
getitimer01.c:54: TPASS: getitimer(tc->which, value) passed
getitimer01.c:55: TPASS: value->it_value.tv_sec == 0 (0)
getitimer01.c:56: TPASS: value->it_value.tv_usec == 0 (0)
getitimer01.c:57: TPASS: value->it_interval.tv_sec == 0 (0)
getitimer01.c:58: TPASS: value->it_interval.tv_usec == 0 (0)
getitimer01.c:61: TPASS: setitimer(tc->which, value, NULL) passed
getitimer01.c:64: TPASS: getitimer(tc->which, value) passed
getitimer01.c:66: TPASS: value->it_interval.tv_sec == SEC (100)
getitimer01.c:67: TFAIL: value->it_interval.tv_usec (12000) != USEC (10000)
getitimer01.c:70: TINFO: value->it_value.tv_sec=100, value->it_value.tv_usec=16000
getitimer01.c:83: TFAIL: value->it_value.tv_usec is out of range: 16000

Summary:
passed 18
failed 2
broken 0
skipped 0
warnings 0
INFO: ltp-pan reported some tests FAIL
LTP Version: 20230516
INFO: Test end time: Tue Jul 4 15:43:36 UTC 2023

[Po-Hsu Lin (cypressyew)]

This issue can be found with T-lts-xenial 4.4.0-244.278~14.04.1 AMD64 instance on openstack with generic kernel.

[Po-Hsu Lin (cypressyew)]

On Xenial 4.4.0-244.278, this is failing on ARM64 instance on openstack with generic kernel (no lowlatency ARM64 for X-4.4)

[Thadeu Lima de Souza Cascardo (cascardo)]

Starting with bionic, itimer will convert timeval to nsec, which is what the kernel will use internally to keep track of itimers. Specially for virtual and proc itimers, before v4.12, the kernel would use jiffies (or some form of it) to convert to/from timeval. And it would keep that conversion internally in the itimers too.

Alternatively, we could argue that we should use virtual accounting instead of tick accounting, but it looks like that would not be possible on those old kernels on amd64 unless we would go full tickless, which we don't want to.

So what is left is to find out why trusty and xenial behave differently here, and why the jiffies conversion doesn't work out with 10000 usec.

Cascardo.

[Thadeu Lima de Souza Cascardo (cascardo)]

On xenial, CONFIG_HZ=250. It does work in multiples of 4000.

The commit below does purport to fix a problem. Perhaps, we should adjust the test to work with these older kernels that still rely on jiffies for the VIRTUAL and PROF itimers intervals, and just make sure that rounding works correctly and the error pointed out by the commit below does not happen.

I don't see what value could be used that would work out for any of HZ=1000, HZ=300, HZ=250 and HZ=100, but perhaps we can ignore HZ=300 and just go with 20'000 usecs (which may just work out with HZ=300).

commit d78c9300c51d6ceed9f6d078d4e9366f259de28c
Author: Andrew Hunter <email address hidden>
Date: Thu Sep 4 14:17:16 2014 -0700

    jiffies: Fix timeval conversion to jiffies

    timeval_to_jiffies tried to round a timeval up to an integral number
    of jiffies, but the logic for doing so was incorrect: intervals
    corresponding to exactly N jiffies would become N+1. This manifested
    itself particularly repeatedly stopping/starting an itimer:

    setitimer(ITIMER_PROF, &val, NULL);
    setitimer(ITIMER_PROF, NULL, &val);

    would add a full tick to val, _even if it was exactly representable in
    terms of jiffies_ (say, the result of a previous rounding.) Doing
    this repeatedly would cause unbounded growth in val. So fix the math.