WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/loongson/dev?h=master 2021-03-11T11:16:54Z 2021-03-11T11:16:54Z jsg jsg@openbsd.org 2021-03-11T11:16:54Z urn:sha1:36fd90dcf1acf2ddb4ef5dbabe5313b3a8d46ee2 2021-01-02T14:29:16Z visa visa@openbsd.org 2021-01-02T14:29:16Z urn:sha1:c3057b41a5542a807ba6ac4ab19f5d2dc88ab09e From Yifei ZHAN on tech@ 2020-12-25T12:59:51Z visa visa@openbsd.org 2020-12-25T12:59:51Z urn:sha1:9b0cf67b268a857fffa6a742ad6be57acdc35301 Rename klist_{insert,remove}() to klist_{insert,remove}_locked(). These functions assume that the caller has locked the klist. The current state of locking remains intact because the kernel lock is still used with all klists. Add new functions klist_insert() and klist_remove() that lock the klist internally. This allows some code simplification. OK mpi@ 2020-10-20T15:59:17Z cheloha cheloha@openbsd.org 2020-10-20T15:59:17Z urn:sha1:ee48eda3aead4d6834f169d8f3655b70f0e4b785 Normally we set hz(9) at compile-time in sys/conf/param.c to the value of HZ. HZ is one of the fundamental compilation options(4). However, sometimes we need to reset hz(9) at runtime. Whenever we reset hz(9) we need to recompute tick and tick_nsec. Otherwise a variety of "time stuff" in the kernel will not work correctly. For example, most timeouts will expire "too slow" or "too fast". There are a bunch of other places we use tick and tick_nsec that will exhibit similar problems. Test-compiled by deraadt@. 2020-09-30T22:23:40Z patrick patrick@openbsd.org 2020-09-30T22:23:40Z urn:sha1:d714ed3db694a238d1e0a5018a7fb156af9527f3 platforms than just loongson. Rename it to mfokrtc(4) for consistency with other RTC drivers. Make it match on st,m41t83, since that was the chip for which the driver was written for. More compatible strings can be added for each chip of the series verified to behave the same. Discussed with kettenis@ Compile tested on loongson by kn@ Tested on loongson by and ok visa@ 2020-07-18T08:59:28Z visa visa@openbsd.org 2020-07-18T08:59:28Z urn:sha1:f17b9b4c1ec17848b29399f91bcb2361c8e1af0e 2020-06-24T22:03:40Z cheloha cheloha@openbsd.org 2020-06-24T22:03:40Z urn:sha1:3209772dfcc3950dd5df01bc44eebf75e637511e time_second(9) and time_uptime(9) are widely used in the kernel to quickly get the system UTC or system uptime as a time_t. However, time_t is 64-bit everywhere, so it is not generally safe to use them on 32-bit platforms: you have a split-read problem if your hardware cannot perform atomic 64-bit reads. This patch replaces time_second(9) with gettime(9), a safer successor interface, throughout the kernel. Similarly, time_uptime(9) is replaced with getuptime(9). There is a performance cost on 32-bit platforms in exchange for eliminating the split-read problem: instead of two register reads you now have a lockless read loop to pull the values from the timehands. This is really not *too* bad in the grand scheme of things, but compared to what we were doing before it is several times slower. There is no performance cost on 64-bit (__LP64__) platforms. With input from visa@, dlg@, and tedu@. Several bugs squashed by visa@. ok kettenis@ 2020-05-29T04:42:23Z deraadt deraadt@openbsd.org 2020-05-29T04:42:23Z urn:sha1:c8f27247b9f5f282483daaddbfd1267ad73569c5 conversion steps). it only contains kernel prototypes for 4 interfaces, all of which legitimately belong in sys/systm.h, which are already included by all enqueue_randomness() users. 2020-05-25T13:16:06Z visa visa@openbsd.org 2020-05-25T13:16:06Z urn:sha1:31413d8a5e31efa5da195515335173fb9aae0b67 Tested on Yeeloong. Looks good to miod@ 2020-05-25T13:15:37Z visa visa@openbsd.org 2020-05-25T13:15:37Z urn:sha1:cffe340de7412f5702d8ab8a5a64c3ad85978b6d Looks good to miod@