wireguard-openbsd/sys/kern, branch jd/simplify-queueingWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/kern?h=jd%2Fsimplify-queueing2020-06-22T18:25:57Zinittodr(9): introduce dedicated flag to enable writes from resettodr(9)2020-06-22T18:25:57Zchelohacheloha@openbsd.org2020-06-22T18:25:57Zurn:sha1:bf2d84a07eb2512358d130f21cd3f3c03b4c2d28
We don't want resettodr(9) to write the RTC until inittodr(9) has
actually run. Until inittodr(9) calls tc_setclock() the system UTC
clock will contain a meaningless value and there's no sense in
overwriting a good value with a value we know is nonsense.
This is not an uncommon problem if you're debugging a problem in early
boot, e.g. a panic that occurs prior to inittodr(9).
Currently we use the following logic in resettodr(9) to inhibit writes:
if (time_second == 1)
return;
... this is too magical.
A better way to accomplish the same thing is to introduce a dedicated
flag set from inittodr(9). Hence, "inittodr_done".
Suggested by visa@.
ok kettenis@
Extend kqueue interface with EVFILT_EXCEPT filter.2020-06-22T13:14:32Zmpimpi@openbsd.org2020-06-22T13:14:32Zurn:sha1:7ab02df9ba969938f0d288bc81680642c429c9c4
This filter, already implemented in macOS and Dragonfly BSD, returns
exceptional conditions like the reception of out-of-band data.
The functionnality is similar to poll(2)'s POLLPRI & POLLRDBAND and
it can be used by the kqfilter-based poll & select implementation.
ok millert@ on a previous version, ok visa@
there's not going to be any whole kernel wide network livelocks soon.2020-06-22T02:45:18Zdlgdlg@openbsd.org2020-06-22T02:45:18Zurn:sha1:0de7037a968aa89f7ec4dba4389f41679183f182add mq_push. it's like mq_enqueue, but drops from the head, not the tail.2020-06-21T05:37:26Zdlgdlg@openbsd.org2020-06-21T05:37:26Zurn:sha1:6281916f49597dc1fbe9d42916a18886ab02a325
from Matt Dunwoodie and Jason A. Donenfeld
backout pipe change, it crashes some arch2020-06-19T02:08:48Zderaadtderaadt@openbsd.org2020-06-19T02:08:48Zurn:sha1:8631d7d972792c6c7fa7099b8e25765d2df2a208Compare `so' and `sosp' types just after `sosp' obtaining. We can't splice2020-06-18T14:05:21Zmvsmvs@openbsd.org2020-06-18T14:05:21Zurn:sha1:6a4f7213e40fa1e06c0f29499c22abd45246ff7c
sockets from different domains so there is no reason to have locking and memory
allocation in this error path. Also in this case only `so' will be locked by
solock() so we should avoid `sosp' modification.
ok mpi@
Instead of performing three distinct allocations per created pipe,2020-06-17T18:29:28Zantonanton@openbsd.org2020-06-17T18:29:28Zurn:sha1:15ad1813789d0ac9ab1cb6bcd5eabf14996ca0d9
reduce it to a single one. Not only should this be more performant, it
also solves a kqueue related issue found by visa@ who also requested
this change: if you attach an EVFILT_WRITE filter to a pipe fd, the
knote gets added to the peer's klist. This is a problem for kqueue
because if you close the peer's fd, the knote is left in the list whose
head is about to be freed. knote_fdclose() is not able to clear the
knote because it is not registered with the peer's fd.
FreeBSD also takes a similar approach to pipe allocations.
ok mpi@ visa@
make intrmap_cpu return a struct cpu_info *, not a "cpuid number" thing.2020-06-17T03:01:26Zdlgdlg@openbsd.org2020-06-17T03:01:26Zurn:sha1:d9f5f731b36c2b84d162b627806286ade4bbe0dd
requested by kettenis@
discussed with jmatthew@
add intrmap, an api that picks cpus for devices to attach interrupts to.2020-06-17T00:27:52Zdlgdlg@openbsd.org2020-06-17T00:27:52Zurn:sha1:7bd9aa6b5ddc24862d0a315074ed76f3f7aa3334
there's been discussions for years (and even some diffs!) about how we
should let drivers establish interrupts on multiple cpus.
the simple approach is to let every driver look at the number of
cpus in a box and just pin an interrupt on it, which is what pretty
much everyone else started with, but we have never seemed to get
past bikeshedding about. from what i can tell, the principal
objections to this are:
1. interrupts will tend to land on low numbered cpus.
ie, if drivers try to establish n interrupts on m cpus, they'll
start at cpu 0 and go to cpu n, which means cpu 0 will end up with more
interrupts than cpu m-1.
2. some cpus shouldn't be used for interrupts.
why a cpu should or shouldn't be used for interrupts can be pretty
arbitrary, but in practical terms i'm going to borrow from the
scheduler and say that we shouldn't run work on hyperthreads.
3. making all the drivers make the same decisions about the above is
a lot of maintenance overhead.
either we will have a bunch of inconsistencies, or we'll have a lot
of untested commits to keep everything the same.
my proposed solution to the above is this diff to provide the intrmap
api. drivers that want to establish multiple interrupts ask the api for
a set of cpus it can use, and the api considers the above issues when
generating a set of cpus for the driver to use. drivers then establish
interrupts on cpus with the info provided by the map.
it is based on the if_ringmap api in dragonflybsd, but generalised so it
could be used by something like nvme(4) in the future.
this version provides numeric ids for CPUs to drivers, but as
kettenis@ has been pointing out for a very long time, it makes more
sense to use cpu_info pointers. i'll be updating the code to address
that shortly.
discussed with deraadt@ and jmatthew@
ok claudio@ patrick@ kettenis@
wire stoeplitz code into the tree.2020-06-16T05:09:28Zdlgdlg@openbsd.org2020-06-16T05:09:28Zurn:sha1:31aecb516e65b13579b7e57d1c38ad0f1da2f8a5