In D55789#1281951, @siva wrote:

This is failing in CI as well: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/28085/testReport/sys.kern/timerfd/timerfd__periodic_timer_performance/

Could you file a bug to track this test failure, and add a atf_tc_expect_fail("https://bugs.freebsd.org/<PR>") to this testcase in the meantime?

This is great. Way clearer logic IMO

Saturate next expiration sbintime

Remove atf-c-leakcheck.h and ALLOW_TIMER_SLACK ifndefs

So then the question becomes: what is the minimum amount of time, in the future, that a callout can be scheduled for without missing its activation time?

Say the next expiration is scheduled to happen in 1ns. Instead of actually scheduling that callout to active in 1ns, should I instead schedule the callout for 2ns in the future and when that activates increment the timerfd count +2?

I think this is especially tricky because it depends on system load, as you mentioned in D55790.

Our mitigation for this in other timer systems is to avoid making such estimates, and instead try to ensure that the system automatically stops the callout if the owning process is killed. See the P_SHOULDSTOP(p) || P_KILLED(p) checks in kern_time.c and kern_event.c.

Hmm, this sounds like another bug. Even if the callout handler is lightweight, I'm sure it plus the overhead of scheduling and running a callout costs more than 1ns. The livelock issue relates to the problem where it becomes impossible to schedule a thread on a looping core, because the softclock thread which runs the callout handler has high priority.

In D55789#1276630, @markj wrote:

A bit tangential, but: we found a while back that it was possible to trivially livelock a core by scheduling timeouts of 1ns using EVFILT_TIMER or setitimer(). Basically, it takes longer than the callout interval to execute the callout handler, so the callout handler ends up running in a loop.

Rewrite timerfd__missed_events test to remove excessive errno
checking.

Like eugen suggested, it might be better to skip the line and log a warning on syntax parse failure instead of terminating. It looks like this would require some more surgery to handle other parse errors though.

Tests added. I forgot to add the review link into the commit message... oops. Closing this.

Use memcpy(3) to copy pci_conf data into compat structures instead of assigning
members one by one.

Good to see more Capsicumization efforts going on. I just had a few pedantic suggestions. Otherwise, this generally looks good.

In D48222#1101641, @markj wrote:

Another option might be to extend connectat(2) to support IP sockets. For instance, connectat(s, {AF_INET, 0.0.0.0, 0}), disallowed in capability, could permit sendto(s) in capability mode. Or, connectat(s, {AF_INET, 192.168.1.0}, 0) permits sendto() to 192.168.1.0/24. This would allow syslogd to transmit to any sockaddr, so weakens the sandbox a bit, but it makes userspace much simpler.

I do not like how complicated this is getting, but the code all looks good.

Thanks for finding and fixing all of these.

In D26456#1087673, @jfree wrote:

In D26456#1087672, @arrowd wrote:

Any progress on this?

Yes, I’ve been working on it. I will try to get them in this weekend. Sorry for the wait

Add missing error checking on memory allocation