Page MenuHomeFreeBSD

fix setitimer test for returned it_value
ClosedPublic

Authored by vangyzen on Sep 15 2020, 7:55 PM.

Details

Summary

An old it_value of {4,3} is valid. Allow it.

Test Plan

Before, testing in a loop would fail around 45%. Printing the old value
showed the vast majority were either {4,2} or {4,3}.

After, testing in a loop never failed.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

This revision is now accepted and ready to land.Sep 15 2020, 8:10 PM
contrib/netbsd-tests/lib/libc/sys/t_getitimer.c
198 ↗(On Diff #77073)

This invariant (the old and the new one) seems a bit curious and racy (in both the FreeBSD and NetBSD cases).

The behavior in the NetBSD case seems more functionally correct, given the documentation, but again.. is racy.

I don't like the new invariant since it shouldn't take longer than 1 usec to complete (the resolution of the system clock with ITIMER_REAL is 10 msec, but I can see where virtual platforms would skew).

Maybe the better way to check this is whether or not the value is within a threshold with timercmp.

I'll poke around and see if NetBSD fixed this a different way.

contrib/netbsd-tests/lib/libc/sys/t_getitimer.c
198 ↗(On Diff #77073)

The behavior of FreeBSD seems more useful. It also matches Linux. POSIX (2013) marks setitimer obsolescent with a recommendation to use timer_settime instead. timer_settime returns "the previous amount of time before the timer would
have expired." That's still not entirely clear, but it seems clear enough.

These timers operate in wall-clock time. The process could get context-switched out between the two syscalls, allowing an unknown amount of time to pass. A VM on an oversubscribed host could get switched out for a long time, possibly making even the current code too restrictive. Granted, that's an extreme case. I could reduce the tolerance to some 100's of ms, but I wouldn't make it any less. (It might be nice to centralize the test suite's idea of allowed timer/scheduler slop, maybe even making it tunable at runtime, but that's out of scope here.)

This revision was automatically updated to reflect the committed changes.