<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 15, 2022 at 7:12 PM Richard Palethorpe <<a href="mailto:rpalethorpe@suse.de">rpalethorpe@suse.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
Li Wang <<a href="mailto:liwang@redhat.com" target="_blank">liwang@redhat.com</a>> writes:<br>
<br>
> On Tue, Nov 15, 2022 at 6:00 PM Li Wang <<a href="mailto:liwang@redhat.com" target="_blank">liwang@redhat.com</a>> wrote:<br>
><br>
> Richard Palethorpe <<a href="mailto:rpalethorpe@suse.de" target="_blank">rpalethorpe@suse.de</a>> wrote:<br>
> <br>
> > <br>
> > Practically speaking we have to assume a large amount of time has passed<br>
> > when using ITIMER_REAL. It has to be *much* larger than a VM is likely<br>
> > to be paused for and then successfully resumed. Or the amount of time a<br>
> > clock may be corrected by (for e.g. with NTP).<br>
> ><br>
> > Hmm, not sure if I understand correctly above, will that<br>
> > timer value be out of the range but reasonable?<br>
> ><br>
> > Or is there any additional situation we should cover?<br>
><br>
> Sorry that is confusing.<br>
><br>
> The question is what happens if the clock jumps backwards?<br></blockquote><div><br></div><div><br></div><div class="gmail_default" style="font-size:small">I did some research on the work theory of setitimer() for modern</div><div class="gmail_default" style="font-size:small">kernels, it seems that situation won't happen, because the kernel</div><div class="gmail_default" style="font-size:small">uses a relative mode for the timer countdown. IOW, once the system</div><div class="gmail_default" style="font-size:small">wall clock getting changed, the timer for the process will update its</div><div class="gmail_default" style="font-size:small">timer relatively.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To verify this I adjust the wall-clock with adding whatever 10 sec or</div><div class="gmail_default" style="font-size:small">24 hour, it all works well and get expected signal:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">--- a/testcases/kernel/syscalls/setitimer/setitimer01.c<br>+++ b/testcases/kernel/syscalls/setitimer/setitimer01.c<br>@@ -21,6 +21,7 @@<br> #include "lapi/syscalls.h"<br> #include "tst_safe_clocks.h"<br> <br>+static struct timespec now;<br> static struct itimerval *value, *ovalue;<br> static volatile unsigned long sigcnt;<br> static long time_step;<br>@@ -33,8 +34,8 @@ static struct tcase {<br> int signo;<br> } tcases[] = {<br> {ITIMER_REAL, "ITIMER_REAL", SIGALRM},<br>- {ITIMER_VIRTUAL, "ITIMER_VIRTUAL", SIGVTALRM},<br>- {ITIMER_PROF, "ITIMER_PROF", SIGPROF},<br>+// {ITIMER_VIRTUAL, "ITIMER_VIRTUAL", SIGVTALRM},<br>+// {ITIMER_PROF, "ITIMER_PROF", SIGPROF},<br> };<br> <br> static int sys_setitimer(int which, void *new_value, void *old_value)<br>@@ -72,6 +73,10 @@ static void verify_setitimer(unsigned int i)<br> set_setitimer_value(time_sec, time_usec);<br> TST_EXP_PASS(sys_setitimer(tc->which, value, NULL));<br> <br>+ now.tv_sec += 20; // 86400s == 24h<br>+ SAFE_CLOCK_SETTIME(CLOCK_REALTIME, &now);<br>+ tst_res(TINFO, "debug only: add 20 secs to now.tv_sec %ld\n", now.tv_sec);<br>+<br> set_setitimer_value(5 * time_sec, 7 * time_usec);<br> TST_EXP_PASS(sys_setitimer(tc->which, value, ovalue));<br> <br>@@ -120,6 +125,9 @@ static void verify_setitimer(unsigned int i)<br> tst_res(TPASS, "Child received signal: %s", tst_strsig(tc->signo));<br> else<br> tst_res(TFAIL, "Child: %s", tst_strstatus(status));<br>+<br>+ SAFE_CLOCK_GETTIME(CLOCK_REALTIME, &now);<br>+ tst_res(TINFO, "debug only: now.tv_sec is %ld\n", now.tv_sec);<br> }<br> <br> static void setup(void)<br>@@ -142,6 +150,9 @@ static void setup(void)<br> <br> time_sec = 9 + time_step / 1000;<br> time_usec = 3 * time_step;<br>+<br>+ SAFE_CLOCK_GETTIME(CLOCK_REALTIME, &now);<br>+ tst_res(TINFO, "debug only: now.tv_sec is %ld\n", now.tv_sec);<br> }<br> <br> static struct tst_test test = {<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Or do you have another better suggestion?<br>
<br>
TBH I don't know if it will happen. An acceptable outcome for me is to<br>
print the time at the beginning and end of the test. Then if the test<br>
fails we can see if it was due to a time jump and start investigating<br>
what the kernel is supposed to do in this case.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">But I think this print is still necessary, in case that some older kernels</div><div class="gmail_default" style="font-size:small">do not use the relative mode for timer. I'll add this and send patch v2.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The alternative is to find out now what the kernel should do. We could<br>
also write a test which deliberately changes the system time during an<br>
interval. Depending how motivated you are.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Thanks!</div><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>