OpenBSD cvs log

created 2020-12-01T16:18:02Z
begin 2020-10-13T00:00:00Z
end 2020-10-14T00:00:00Z
path src/sys
commits 4

date 2020-10-13T05:03:03Z
author jsg
files src/sys/dev/pci/drm/i915/gem/i915_gem_shmem.c log diff annotate
message move ifdef to make it clear we don't use __create_shmem()

date 2020-10-13T08:47:59Z
author mpi
files src/sys/uvm/uvm_unix.c log diff annotate
message typo in comment

date 2020-10-13T16:43:44Z
author cheloha
files src/sys/kern/kern_time.c log diff annotate
message setitimer(2): realitexpire(): call getnanouptime(9) once

timespecadd(3) is fast. There is no need to call getnanouptime(9)
repeatedly when searching for the next expiration point. Given that
it_interval is at least 1/hz, we expect to run through the loop maybe
hz times at most. Even at HZ=10000 that's pretty brief.

While we're here, pull *all* of the other logic out of the loop.
The only thing we need to do in the loop is timespecadd(3).

date 2020-10-13T17:33:39Z
author cheloha
files src/sys/kern/kern_time.c log diff annotate
message setitimer(2): zero itv.it_interval if itv.it_value is zero

If itv.it_value is zero we cancel the timer. When we cancel the timer
we don't care about itv.it_interval because the timer is not running:
we don't use it, we don't look at it, etc.

To be on the paranoid side, I think we should zero itv.it_interval
when itv.it_value is zero. No need to write arbitrary values into the
process struct if we aren't required to. The standard is ambiguous
about what should happen in this case, i.e. the value of olditv after
the following code executes is unspecified:

struct itimerval newitv, olditv;

newitv.it_value.tv_sec = newitv.it_value.tv_usec = 0;
newitv.it_interval.tv_sec = newitv.it_interval.tv_usec = 1;
setitimer(ITIMER_REAL, &newitv, NULL);
getitimer(ITIMER_REAL, &olditv);

This change should not break any real code.