src/tests/sys/kqueue/libkqueue/timer.c, branch release/13.1.0

kqueue: don't arbitrarily restrict long-past values for NOTE_ABSTIME

2021-10-06T07:03:53Z

NOTE_ABSTIME values are converted to values relative to boottime in filt_timervalidate(), and negative values are currently rejected. We don't reject times in the past in general, so clamp this up to 0 as needed such that the timer fires immediately rather than imposing what looks like an arbitrary restriction. Another possible scenario is that the system clock had to be adjusted by ~minutes or ~hours and we have less than that in terms of uptime, making a reasonable short-timeout suddenly invalid. Firing it is still a valid choice in this scenario so that applications can at least expect a consistent behavior. (cherry picked from commit 9c999a259f00b35f0467acd351fea9157ed7e1e4) (cherry picked from commit 2f4dbe279f6b5eb87ec493d96f6943ffdb603ba0)

tests: kqueue: fix some issues with now() on ILP32 platforms

2020-04-20T00:47:28Z

There were ultimately two separate problems here: - a 32-bit long cannot represent microseconds since 1970 (noted by ian) - time_t is 32-bit on i386, so now() was wrong anyways even with the correct return type. For the first, just explicitly use a uint64_t for now() and all of the callers. For the second, we need to explicitly cast tv_sec to uint64_t before it gets multiplied in the SEC_TO_US macro. Casting this instance rather than generally in the macro was arbitrarily chosen simply because all other uses are converting small relative time values. The tests now pass on i386, at least; presumably other ILP32 will be fine now as well.

Fix various warnings in tests/sys/kqueue and bump WARNS

2020-04-18T12:54:47Z

Reviewed By: kevans Differential Revision: https://reviews.freebsd.org/D24296

tests: kqueue: use a more precise timer for the NOTE_ABSTIME test

2020-04-17T02:22:15Z

Originally noticed while attempting to run the kqueue tests under qemu-user-static, this apparently just happens sometimes when running in a jail in general -- the timer will fire off "too early," but it's really just the result of imprecise measurements (noted by cem). Kicking this over to NOTE_USECONDS still tests the correct thing while allowing it to work more consistently; a basic sanity test reveals that we often end up coming in just less than 200 microseconds after the timer fired off. MFC after: 3 days

kqueue tests: fix -fno-common build

2020-04-06T23:08:07Z

vnode_fd and kqfd are both shared among multiple CU; define them exactly once. In the case of vnode_fd, it was simply the declaration that needed correction. -fno-common will become the default in GCC10/LLVM11. MFC after: 3 days

Make whitespace more consistent in libkqueue tests.

2018-11-27T15:12:34Z

After r337820, which "corrected" some spaces-instead-of-tab whitespace issues in the libkqueue tests, jmg@ pointed out that these files were originally space-based, not tab-spaced, and so the correction should have been to get rid of the tabs that had been introduced in previous changes, not the spaces. This change does that. This is a whitespace only change; no functional change is intended. Reported by: jmg@ MFC after: 3 days Sponsored by: Dell EMC Isilon

Correct possible misleading error message in kqtest.

2018-07-30T14:21:49Z

ian@ pointed out that in the test_abstime() function time(NULL) is used twice; once in an "if" test and again in the enclosed error message. If the true branch was taken and the process got preempted before the second time(NULL) call, by the time the error message was generated enough time could have elapsed that the message could claim that the event came "too early" but print an event time that was after the expected timeout. Correct by making the time(NULL) call only once and using that returned time in both the "if" test and the error message. Reported by: ian@ MFC after: 4 days X-MFC-with: r336761, r336781, r336802 Sponsored by: Dell EMC

Fix compilation error on some arches after r336761 & r336781.

2018-07-28T02:53:36Z

Another cast for printing an intmax_t was needed in a kqueue test for some arches. Pointy-hat: me (twice) MFC after: 1 week X-MFC-with: r336761, r336781 Sponsored by: Dell EMC

Fix compilation error on some arches after r336761.

2018-07-27T20:14:58Z

A cast for printing an intmax_t was needed in a kqueue test for some arches. MFC after: 1 week X-MFC-with: r336761 Sponsored by: Dell EMC

Allow a EVFILT_TIMER kevent to be updated.

2018-07-27T13:49:17Z

If a timer is updated (re-added) with a different time period (specified in the .data field of the kevent), the new time period has no effect; the timer will not expire until the original time has elapsed. This violates the documented behavior as the kqueue(2) man page says (in part) "Re-adding an existing event will modify the parameters of the original event, and not result in a duplicate entry." This modification, adapted from a patch submitted by cem@ to PR214987, fixes the kqueue system to allow updating a timer entry. The kevent timer behavior is changed to: * When a timer is re-added, update the timer parameters to and re-start the timer using the new parameters. * Allow updating both active and already expired timers. * When the timer has already expired, dequeue any undelivered events and clear the count of expirations. All of these changes address the original PR and also bring the FreeBSD and macOS kevent timer behaviors into agreement. A few other changes were made along the way: * Update the kqueue(2) man page to reflect the new timer behavior. * Fix man page style issues in kqueue(2) diagnosed by igor. * Update the timer libkqueue system test to test for the updated timer behavior. * Fix the (test) libkqueue common.h file so that it includes config.h which defines various HAVE_* feature defines, before the #if tests for such variables in common.h. This enables the use of the actual err(3) family of functions. * Fix the usages of the err(3) functions in the tests for incorrect type of variables. Those were formerly undiagnosed due to the disablement of the err(3) functions (see previous bullet point). PR: 214987 Reported by: Brian Wellington Reviewed by: kib MFC after: 1 week Relnotes: yes Sponsored by: Dell EMC Differential Revision: https://reviews.freebsd.org/D15778