<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 Fri, May 13, 2022 at 10:20 PM Cyril Hrubis <<a href="mailto:chrubis@suse.cz">chrubis@suse.cz</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">Hi!<br>
> > > I hit a new problem while testing new pty03, that seems here<br>
> > > will fall into an infinite loop and test timed out finally. The printf<br>
> > > shows rem_p will be overflow I haven't figured out why.<br>
> > ><br>
> > > But with comparing with 0.9, it always gets passed on to the same system.<br>
> ><br>
> > That is strange, since we do:<br>
> ><br>
> >         rem_p = 1 - tst_remaining_runtime()/pair->time_exec_start;<br>
> ><br>
> <br>
> I guess the root cause is that 'pair->time_exec_start' has a possibility<br>
> to reach zero. in pty03 it has ".tcnt = 9" which made the<br>
> tst_fzsync_pair_reset()<br>
> to be re-run many times, but in that function 'pair->time_exec_start' will<br>
> be set only based on the original .max_runtime, with time elapsed the<br>
> remaining time tends to be zero.<br>
<br>
I guess that that the interaction of tcnt and runtime is not optimal<br>
here. You are right that as long as we call tst_fzsync_pair_reset() on<br>
each invocation of the run() function we may eventually get to state<br>
where the runtime is exhausted, especially on slower hardware we end up<br>
with division by zero and overflow.<br>
<br>
The cleanest solution would be to rewrite the test to use .test_variants = 9<br>
and setting the .max_runtime to a smaller value. That way we would have<br>
precisely defined runtime for each iteration. What do you think?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, that should work, but people have to painstakingly remember</div><div class="gmail_default" style="font-size:small">that to avoid this interaction of tcnt and runtime in test writing. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Another simple choice I can think of is to use tst_set_max_runtime()</div><div class="gmail_default" style="font-size:small">to reset both 'timeout' and 'runtime' at the beginning of each invocation</div><div class="gmail_default" style="font-size:small">of the run(). </div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And maybe we should invoke it in the <span class="gmail_default"></span>tst_fzsync_pair_reset directly?</div><div class="gmail_default" style="font-size:small">I'm not very sure about fixing this in fzsync-lib or out.</div><div><br></div><div><div class="gmail_default" style="font-size:small">--- a/testcases/kernel/pty/pty03.c</div>+++ b/testcases/kernel/pty/pty03.c<br>@@ -105,6 +105,7 @@ static void do_test(unsigned int n)<br> <br>        tst_res(TINFO, "Creating PTY with %s line discipline", ldisc->name);<br> <br>+       tst_set_max_runtime(test.<span class="gmail_default" style="font-size:small">runtime</span>);<br>        <span class="gmail_default" style="font-size:small"></span>tst_fzsync_pair_reset(&fzp, hangup);<br>        while (tst_fzsync_run_a(&fzp)) {<br>                ptmx = SAFE_OPEN("/dev/ptmx", O_RDONLY);<br><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>