[LTP] [PATCH 1/2] setitimer01: add interval timer test

[Li Wang]

On Tue, Nov 15, 2022 at 7:12 PM Richard Palethorpe <rpalethorpe@suse.de>
wrote:

> Hello,
>
> Li Wang <liwang@redhat.com> writes:
>
> > On Tue, Nov 15, 2022 at 6:00 PM Li Wang <liwang@redhat.com> wrote:
> >
> >  Richard Palethorpe <rpalethorpe@suse.de> wrote:
> >
> >  >
> >  >  Practically speaking we have to assume a large amount of time has
> passed
> >  >  when using ITIMER_REAL. It has to be *much* larger than a VM is
> likely
> >  >  to be paused for and then successfully resumed. Or the amount of
> time a
> >  >  clock may be corrected by (for e.g. with NTP).
> >  >
> >  > Hmm, not sure if I understand correctly above, will that
> >  > timer value be out of the range but reasonable?
> >  >
> >  > Or is there any additional situation we should cover?
> >
> >  Sorry that is confusing.
> >
> >  The question is what happens if the clock jumps backwards?
>


I did some research on the work theory of setitimer() for modern
kernels, it seems that situation won't happen, because the kernel
uses a relative mode for the timer countdown. IOW, once the system
wall clock getting changed, the timer for the process will update its
timer relatively.

To verify this I adjust the wall-clock with adding whatever 10 sec or
24 hour, it all works well and get expected signal:

--- a/testcases/kernel/syscalls/setitimer/setitimer01.c
+++ b/testcases/kernel/syscalls/setitimer/setitimer01.c
@@ -21,6 +21,7 @@
 #include "lapi/syscalls.h"
 #include "tst_safe_clocks.h"

+static struct timespec now;
 static struct itimerval *value, *ovalue;
 static volatile unsigned long sigcnt;
 static long time_step;
@@ -33,8 +34,8 @@ static struct tcase {
        int signo;
 } tcases[] = {
        {ITIMER_REAL,    "ITIMER_REAL",    SIGALRM},
-       {ITIMER_VIRTUAL, "ITIMER_VIRTUAL", SIGVTALRM},
-       {ITIMER_PROF,    "ITIMER_PROF",    SIGPROF},
+//     {ITIMER_VIRTUAL, "ITIMER_VIRTUAL", SIGVTALRM},
+//     {ITIMER_PROF,    "ITIMER_PROF",    SIGPROF},
 };

 static int sys_setitimer(int which, void *new_value, void *old_value)
@@ -72,6 +73,10 @@ static void verify_setitimer(unsigned int i)
                set_setitimer_value(time_sec, time_usec);
                TST_EXP_PASS(sys_setitimer(tc->which, value, NULL));

+               now.tv_sec += 20; // 86400s == 24h
+               SAFE_CLOCK_SETTIME(CLOCK_REALTIME, &now);
+               tst_res(TINFO, "debug only: add 20 secs to now.tv_sec
%ld\n", now.tv_sec);
+
                set_setitimer_value(5 * time_sec, 7 * time_usec);
                TST_EXP_PASS(sys_setitimer(tc->which, value, ovalue));

@@ -120,6 +125,9 @@ static void verify_setitimer(unsigned int i)
                tst_res(TPASS, "Child received signal: %s",
tst_strsig(tc->signo));
        else
                tst_res(TFAIL, "Child: %s", tst_strstatus(status));
+
+       SAFE_CLOCK_GETTIME(CLOCK_REALTIME, &now);
+       tst_res(TINFO, "debug only: now.tv_sec is %ld\n", now.tv_sec);
 }

 static void setup(void)
@@ -142,6 +150,9 @@ static void setup(void)

        time_sec  = 9 + time_step / 1000;
        time_usec = 3 * time_step;
+
+       SAFE_CLOCK_GETTIME(CLOCK_REALTIME, &now);
+       tst_res(TINFO, "debug only: now.tv_sec is %ld\n", now.tv_sec);
 }

 static struct tst_test test = {


>  Or do you have another better suggestion?
>
> TBH I don't know if it will happen. An acceptable outcome for me is to
> print the time at the beginning and end of the test. Then if the test
> fails we can see if it was due to a time jump and start investigating
> what the kernel is supposed to do in this case.
>

But I think this print is still necessary, in case that some older kernels
do not use the relative mode for timer. I'll add this and send patch v2.


> The alternative is to find out now what the kernel should do. We could
> also write a test which deliberately changes the system time during an
> interval. Depending how motivated you are.
>

Thanks!


-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20221116/74e416cd/attachment.htm>