Fix the clock_gettime() handler for pthread_getcpuclockid() to
use the proper way to read tu_runtime.
OK mpi@

Trace struct itimerval

ok deraadt@ claudio@

Rework per proc and per process time usage accounting

For procs (threads) the accounting happens now lockless by curproc using
a generation counter. Callers need to use tu_enter() and tu_leave() for

Rework per proc and per process time usage accounting

For procs (threads) the accounting happens now lockless by curproc using
a generation counter. Callers need to use tu_enter() and tu_leave() for this.
To read the proc p_tu struct tuagg_get_proc() should be used. It ensures
that the values read is consistent.

For processes only the time of exited threads is accumulated in ps_tu and
to get the proper process time usage tuagg_get_process() needs to be called.
tuagg_get_process() will sum up all procs p_tu plus the ps_tu.

This removes another SCHED_LOCK() dependency. Adjust the code in
exit1() and exit2() to correctly account for the full run time.
For this adjust sched_exit() to do the runtime accounting like it is done
in mi_switch().

OK jca@ dlg@

show more ...

clockintr: move callback-specific API behaviors to "clockrequest" namespace

The API's behavior when invoked from a callback function is impossible
to document. Move the special behavior into a dist

clockintr: move callback-specific API behaviors to "clockrequest" namespace

The API's behavior when invoked from a callback function is impossible
to document. Move the special behavior into a distinct namespace,
"clockrequest".

- Add a 'struct clockrequest'. Basically a stripped-down 'struct clockintr'
for exclusive use during clockintr_dispatch().
- In clockintr_queue, replace the "cq_shadow" clockintr with a "cq_request"
clockrequest. They serve the same purpose.
- CLST_SHADOW_PENDING -> CR_RESCHEDULE; different namespace, same meaning.
- CLST_IGNORE_SHADOW -> CLST_IGNORE_REQUEST; same meaning.
- Move shadow branch in clockintr_advance() to clockrequest_advance().
- clockintr_request_random() becomes clockrequest_advance_random().
- Delete dead shadow branches in clockintr_cancel(), clockintr_schedule().
- Callback functions now get a clockrequest pointer instead of a special
clockintr pointer: update all prototypes, callers.

No functional change intended.

show more ...

clockintr: support an arbitrary callback function argument

Callers can now provide an argument pointer to clockintr_establish().
The pointer is kept in a new struct clockintr member, cl_arg. The
po

clockintr: support an arbitrary callback function argument

Callers can now provide an argument pointer to clockintr_establish().
The pointer is kept in a new struct clockintr member, cl_arg. The
pointer is passed as the third parameter to clockintr.cl_func when it
is executed during clockintr_dispatch(). Like the callback function,
the callback argument is immutable after the clockintr is established.

At present, nothing uses this. All current clockintr_establish()
callers pass a NULL arg pointer. However, I am confident that dt(4)'s
profile provider will need this in the near future.

Requested by dlg@ back in March.

show more ...

Remove p_rtime from struct proc and replace it by passing the timespec
as argument to the tuagg_locked function.

- Remove incorrect use of p_rtime in other parts of the tree. p_rtime was
almost alwa

Remove p_rtime from struct proc and replace it by passing the timespec
as argument to the tuagg_locked function.

- Remove incorrect use of p_rtime in other parts of the tree. p_rtime was
almost always 0 so including it in any sum did not alter the result.
- In main() the update of time can be further simplified since at that time
only the primary cpu is running.
- Add missing nanouptime() call in cpu_hatch() for hppa
- Rename tuagg_unlocked to tuagg_locked like it is done in the rest of
the tree.

OK cheloha@ dlg@

show more ...

hardclock(9): move setitimer(2) code into itimer_update()

- Move the setitimer(2) code responsible for updating the ITIMER_VIRTUAL
and ITIMER_PROF timers from hardclock(9) into a new clock interru

hardclock(9): move setitimer(2) code into itimer_update()

- Move the setitimer(2) code responsible for updating the ITIMER_VIRTUAL
and ITIMER_PROF timers from hardclock(9) into a new clock interrupt
routine, itimer_update(). itimer_update() is periodic and runs at the
same frequency as the hardclock.

+ Revise itimerdecr() to run within itimer_mtx instead of entering
and leaving it.

- Each schedstate_percpu has its own itimer_update() handle, spc_itimer.
A new scheduler flag, SPCF_ITIMER, indicates whether spc_itimer was
started during the last mi_switch() and needs to be stopped during the
next mi_switch() or sched_exit().

- A new per-process flag, PS_ITIMER, indicates whether ITIMER_VIRTUAL
and/or ITIMER_PROF are running. Checking the flag is easier than
entering itimer_mtx to check process.ps_timer[]. The flag is set
and cleared in a new helper function, process_reset_itimer_flag().

- In setitimer(), call need_resched() when the state of ITIMER_VIRTUAL
or ITIMER_PROF is changed to force an mi_switch() and update
spc_itimer.

claudio@ notes that ITIMER_PROF could be implemented as a high-res
timer using the thread's execution time as a guide for when to
interrupt the process and assert SIGPROF. This would probably work
really well in single-threaded processes. ITIMER_VIRTUAL would be
more difficult to make high-res, though, as you need to exclude time
spent in the kernel.

Tested on powerpc64 by gkoehler@. With input from claudio@.

Thread: https://marc.info/?l=openbsd-tech&m=169038818517101&w=2

ok claudio@

show more ...

Use the nowake channel for sys_nanosleep() instead of handrolling the same.
OK cheloha@ jca@ mvs@

kernel: stathz is always non-zero after cpu_initclocks()

Now that the clockintr switch is complete, cpu_initclocks() always
initializes stathz to a non-zero value. We don't call statclock()
from ha

kernel: stathz is always non-zero after cpu_initclocks()

Now that the clockintr switch is complete, cpu_initclocks() always
initializes stathz to a non-zero value. We don't call statclock()
from hardclock(9) anymore and, more broadly, we don't need to test
whether stathz is non-zero before using it.

With input from kettenis@.

Link: https://marc.info/?l=openbsd-tech&m=167434223309668&w=2

ok kettenis@ miod@

show more ...

Add tfind_user(), for getting a proc* given a user-space TID and
the process* that it should be part of. Use that in clock_get{time,res}(),
thrkill(), and ptrace().

ok jca@ miod@ mpi@ mvs@

timeout: rename "timeout_at_ts" to "timeout_abs_ts"

I think "abs" ("absolute timeout") is a better mnemonic than
"at" ("at the given time").

The interface is undocumented and there are only two cal

timeout: rename "timeout_at_ts" to "timeout_abs_ts"

I think "abs" ("absolute timeout") is a better mnemonic than
"at" ("at the given time").

The interface is undocumented and there are only two callers, so
renaming it is not a big deal.

probably ok kn@

show more ...

zap a pile of dangling tabs

Extend struct todr_chip_handle with a todr_quality member. This allows us
to assign a quality to RTC implementation and pick the "best" RTC if a
system has multiple RTCs (or multiple interfaces to a

Extend struct todr_chip_handle with a todr_quality member. This allows us
to assign a quality to RTC implementation and pick the "best" RTC if a
system has multiple RTCs (or multiple interfaces to an RTC). This allows
us to prefer a battery-backed I2C RTC over an RTC that is part of the SoC
which is only running of the SoC is powered. It also allows us to
work around issues with firmware RTC interfaces that may lie to us or
even crash the system.

This change makes sure the todr_quality member of the struct is always
initialized. In most cases the quality will be set to zero; further
adjustments of the quality for specific subsystems/architectures will follow.

ok cheloha@, patrick@

show more ...

remove unneeded includes in sys/kern
ok mpi@ miod@

Using mutex initializer for static variable does not compile with
witness. Make ratecheck mutex global.
Reported-by: syzbot+9864ba1338526d0e8aca@syzkaller.appspotmail.com

Introduce mutex for ratecheck(9) and ppsratecheck(9). A global
mutex with spl high for all function calls is used for now. It
protects the lasttime and curpps parameter. This solution is MP
safe f

Introduce mutex for ratecheck(9) and ppsratecheck(9). A global
mutex with spl high for all function calls is used for now. It
protects the lasttime and curpps parameter. This solution is MP
safe for the usual use case, allows progress, and can be optimized
later. Remove a useless #if 1 while there.
OK claudio@

show more ...

setitimer(2): increase timer limit to UINT_MAX seconds

Currently setitimer(2) rejects timers larger than 100 million seconds
and sets EINVAL.

With the change to kclock timeouts there is no longer a

setitimer(2): increase timer limit to UINT_MAX seconds

Currently setitimer(2) rejects timers larger than 100 million seconds
and sets EINVAL.

With the change to kclock timeouts there is no longer any reason to
use this arbitrary value. Kclock timeouts support the full range of a
timespec, so we can increase the upper bound without practical risk of
arithmetic overflow.

If we push the limit to UINT_MAX we can support the full input range
of alarm(3). We can then simplify the alarm.3 manpage in a separate
patch.

We can push the limit even higher in the future if we find software
that doesn't like the UINT_MAX limit. Until then, UINT_MAX seconds
(over 68 years) is plenty for all practical timers.

ok claudio@

show more ...

setitimer(2): don't round up it_value

We can reduce latency for the first expiration of a timer if we don't
round it_value up to the minimum interval (1 tick).

While we're at it, we may as well con

setitimer(2): don't round up it_value

We can reduce latency for the first expiration of a timer if we don't
round it_value up to the minimum interval (1 tick).

While we're at it, we may as well consolidate all input validation and
adjustment into a single itimerfix() call. There are no other callers
in the kernel (nor should there be), so remove the prototype from
sys/time.h.

Discussion: https://marc.info/?l=openbsd-tech&m=162084338005502&w=2

Tested by weerd@ and claudio@.

probably ok claudio@

show more ...

Redefine ADJFREQ_MIN to avoid undefined behaviour (when not using -fwrapv)

Change the definition of ADJFREQ_MIN so that it does not shift
a negative value. Such shifting is undefined in standard C.

Redefine ADJFREQ_MIN to avoid undefined behaviour (when not using -fwrapv)

Change the definition of ADJFREQ_MIN so that it does not shift
a negative value. Such shifting is undefined in standard C.

This came up when cross-compiling the kernel using ports clang.
The shifting becomes defined when compiling with option -fwrapv.
Base clang enables this option by default.

OK naddy@ cheloha@

show more ...

nanosleep(2): shorten wmesg from "nanosleep" to "nanoslp"

We only see 8 characters of wmesg in e.g. top(1), so shorten the
string to fit.

Indirectly prompted by kettenis@.

setitimer(2): ITIMER_REAL: protect state with per-process mutex ps_mtx

To unlock getitimer(2) and setitimer(2) we need to protect the
per-process ITIMER_REAL state with something other than the kern

setitimer(2): ITIMER_REAL: protect state with per-process mutex ps_mtx

To unlock getitimer(2) and setitimer(2) we need to protect the
per-process ITIMER_REAL state with something other than the kernel
lock. As the ITIMER_REAL timeout callback realitexpire() runs at
IPL_SOFTCLOCK the per-process mutex ps_mtx is appropriate.

In setitimer() we need to use ps_mtx instead of the global itimer_mtx
if the given timer is ITIMER_REAL. Easy.

The ITIMER_REAL timeout callback routine realitexpire() is trickier.
When we enter ps_mtx during the callback we need to check if the timer
was cancelled or rescheduled. A thread from the process can call
setitimer(2) at the exact moment the callback is about to run from
timeout_run() (see kern_timeout.c).

Update the locking annotation in sys/proc.h accordingly.

ok anton@

show more ...

setitimer(2): ITIMER_REAL: use kclock timeouts

Reimplement the ITIMER_REAL interval timer with a kclock timeout.

Couple things of note:

- We need to use the high-res nanouptime(9) call, not the lo

setitimer(2): ITIMER_REAL: use kclock timeouts

Reimplement the ITIMER_REAL interval timer with a kclock timeout.

Couple things of note:

- We need to use the high-res nanouptime(9) call, not the low-res
getnanouptime(9).
- The code is simpler now that we aren't working with ticks.

Misc. thoughts:

- Still unsure if "kclock" is the right name for these things.
- MP-safely cancelling a periodic timeout is very difficult.

show more ...

_exit(2), execve(2): tweak per-process interval timer cancellation

If we fold the for-loop iterating over each interval timer into the
helper function the result is slightly tidier than what we have

_exit(2), execve(2): tweak per-process interval timer cancellation

If we fold the for-loop iterating over each interval timer into the
helper function the result is slightly tidier than what we have now.
Rename the helper function "cancel_all_itimers".

Based on input from millert@ and kettenis@.

show more ...

_exit(2), execve(2): cancel per-process interval timers safely

During _exit(2) and sometimes during execve(2) we need to cancel any
active per-process interval timers. We don't currently do this in

_exit(2), execve(2): cancel per-process interval timers safely

During _exit(2) and sometimes during execve(2) we need to cancel any
active per-process interval timers. We don't currently do this in an
MP-safe way. Both syscalls ignore the locking assumptions documented
in proc.h.

The easiest way to make them MP-safe is to use setitimer(), just like
the getitimer(2) and setitimer(2) syscalls do. To make things a bit
cleaner I have added a helper function, cancelitimer(), so the callers
don't need to fuss with an itimerval struct.

While we're here we can remove the splclock/splx dance from execve(2).
It is no longer necessary.

ok deraadt@

show more ...

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

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.

show more ...