WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/hppa/include?h=jd%2Fqueueboosts 2020-06-14T20:29:13Z 2020-06-14T20:29:13Z naddy naddy@openbsd.org 2020-06-14T20:29:13Z urn:sha1:2207d07413d2edf062148b9e5cdfa5b0a24c2bf2 ok dlg@ deraadt@ 2020-05-31T06:23:56Z dlg dlg@openbsd.org 2020-05-31T06:23:56Z urn:sha1:01802d2cc63d886227ab3b39e923ff13cf516166 rnd.c uses nanotime to get access to some bits that change quickly between events that it can mix into the entropy pool. it doesn't use nanotime to get a monotonically increasing set or ordered and accurate timestamps, it just wants something with bits that change. there's been discussions for years about letting rnd use a clock that's super fast to read, but not necessarily accurate, but it wasn't until recently that i figured out it wasn't interested in time at all, so things like keeping a fast clock coherent between cpu cores or correct according to ntp is unecessary. this means we can just let rnd read the cycle counters on cpus and things will be fine. cpus with cycle counters that vary in their speed and arent kept consistent between cores may even be desirable in this context. so this is the first step in converting rnd.c to reading cycle counter. it copies the nanotime backend to each arch, and they can replace it with something MD as a second step later on. djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits. thanks to visa for his eyes. ok deraadt@ visa@ deraadt@ says he will help handle any MD fallout that occurs. 2020-05-27T15:16:04Z visa visa@openbsd.org 2020-05-27T15:16:04Z urn:sha1:9df0f941a91e9f67cc4e63514cb174cb2a5783fd Nothing uses the header anymore. OK deraadt@ mpi@ 2019-11-07T14:44:52Z mpi mpi@openbsd.org 2019-11-07T14:44:52Z urn:sha1:6d6b8a876ccc0691e0769b505db074d6e7d968ef 2019-04-23T13:35:12Z visa visa@openbsd.org 2019-04-23T13:35:12Z urn:sha1:8c00de5e511bb647ae228590153001775e12ff38 Reduce code clutter by removing the file name and line number output from witness(4). Typically it is easy enough to locate offending locks using the stack traces that are shown in lock order conflict reports. Tricky cases can be tracked using sysctl kern.witness.locktrace=1 . This patch additionally removes the witness(4) wrapper for mutexes. Now each mutex implementation has to invoke the WITNESS_*() macros in order to utilize the checker. Discussed with and OK dlg@, OK mpi@ 2018-12-05T10:28:21Z jsg jsg@openbsd.org 2018-12-05T10:28:21Z urn:sha1:1a1181a966226532433438cb3741ae7cdc0727d4 including cpu.h machine/intr.h etc without first including param.h when MULTIPROCESSOR is defined. ok visa@ 2018-09-14T13:58:20Z claudio claudio@openbsd.org 2018-09-14T13:58:20Z urn:sha1:965127f80578c0400be53e4188190c636e97095a 4MB which is far too low especially when the platform is able to run MP. New limits are, amd64 = 256M; arm64, mips64, sparc64 = 64M; alpha, arm, hppa, i386, powerpc = 32M; m88k, sh = 8M Still rather conservative numbers but much better than before. At least some hangs of arm64 build boxes was caused by this. OK kettenis@, visa@ 2018-06-08T15:38:52Z guenther guenther@openbsd.org 2018-06-08T15:38:52Z urn:sha1:9845d791983044e23a2356b6adb5c89eb6b18bb7 ok visa@ 2018-05-14T09:33:20Z kettenis kettenis@openbsd.org 2018-05-14T09:33:20Z urn:sha1:ca950ec43995bb7d9640f1f39d8be4c78a3e7360 ok visa@, mpi@ 2018-03-05T01:15:24Z deraadt deraadt@openbsd.org 2018-03-05T01:15:24Z urn:sha1:ea0d1f1fdbdc98dc215aafd8869e67812566a636 needs (looking at you sgi, but others required this before). This is for the circumstances we need pagesize known at compile time, not getpagesize() runtime. Use it for malloc storage sizes, for shm, and to set pthread stack default sizes. The stack sizes were a mess, and pushing them towards page-aligned is healthy move (which will also be needed by the coming stack register checker) ok guenther kettenis, discussion with stefan