[LTP] [PATCH v1] Correctly handle user time in setitimer01

[Li Wang]

On Fri, Nov 4, 2022 at 11:44 PM Martin Doucha <mdoucha@suse.cz> wrote:

> On 04. 11. 22 15:20, Andrea Cervesato wrote:
> > Hi!
> >
> > On 11/4/22 13:46, Martin Doucha wrote:
> >> This approach looks like it'll lead to some bad edge cases when
> >> 0 < time_step < 1000. It'd be better to keep the original time_step
> >> detection and initialize "error" variable like this (and also rename
> >> it to "margin"):
> >>
> >> int jiffy;
> >>
> >> verify_setitimer()
> >> {
> >>     ...
> >>     margin = (tc->which == ITIMER_REAL) ? 0 : jiffy;
> > Here we can't take in consideration CLOCK_MONOTONIC_COARSE resolution by
> > default, because on ITIMER_REAL we are having a clock resolution given
> > by CLOCK_MONOTONIC. And unfortunately we are not sure it's under the
> > millisecond resolution all the times, which means margin > 0. For this
> > reason, in the patch we are fetching clock resolution in a different
> > way, according with the counter timer. We can fetch different
> > resolutions from setup tho and using inside the test code.
>
> There is nothing preventing you from using CLOCK_MONOTONIC_COARSE
> resolution as time_step even for ITIMER_REAL. The only constraints are
> that the timer value must be:
> 1) higher than CLOCK_MONOTONIC resolution (preferably a multiple of it)



> 2) large enough so that you can call setitimer() again before the timer
> expires

Just finding a proper size should be fine, because next I plan to
split ovalue check from the signal test. That means we can give both
SEC and USEC for setitimer() verification.

Also, the interval timer should be tested as well, it will be rebased
(on this problem fixing) in a separate patch.


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