wireguard-openbsd/sys/kern/kern_malloc.c, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/kern/kern_malloc.c?h=jd%2Fqueueboosts 2019-12-19T17:40:10Z Convert infinite sleeps to {m,t}sleep_nsec(9). 2019-12-19T17:40:10Z mpi mpi@openbsd.org 2019-12-19T17:40:10Z urn:sha1:babb761de1ba2d43bc3717c713c02b0d14e11db2 ok visa@ Delete km_mapblocks from kmemstats and its always-zero column from the ddb 2019-11-28T16:23:11Z guenther guenther@openbsd.org 2019-11-28T16:23:11Z urn:sha1:610978bc30c2dcf800971595e08295bf97ab31eb "show malloc" output ok deraadt@ mpi@ rework the zero warning slightly, and more completely disable until we're 2019-05-15T21:25:50Z tedu tedu@openbsd.org 2019-05-15T21:25:50Z urn:sha1:d3ca61021b64d604115fd4a68460452e144a6e49 more ready to deal with the noise. disable stack printing for now since at least arm64 can't print them 2019-05-09T14:09:01Z tedu tedu@openbsd.org 2019-05-09T14:09:01Z urn:sha1:2dec572bb30d2fc161a9c59556e190f326155186 reported by kettenis print a few warnings when calling free with a zero size. 2019-05-08T23:53:26Z tedu tedu@openbsd.org 2019-05-08T23:53:26Z urn:sha1:5cb550263ac27de67bb0c7ef9d929ae7e71afa30 let's see what falls out. ok beck deraadt kettenis mpi In free(9) call wakeup() after mtx_leave() consistently. 2018-07-10T10:17:42Z bluhm bluhm@openbsd.org 2018-07-10T10:17:42Z urn:sha1:4120fcf020f61857e7a04e965b4dc1885dbe3a8b OK kettenis@ visa@ mpi@ Fix trailing whitespaces and too long line. 2018-07-09T20:02:18Z bluhm bluhm@openbsd.org 2018-07-09T20:02:18Z urn:sha1:5c57e1c5403c620af61b54abb974671d8db93646 Make free(9) MP safe. It was wrong to set ku_indx to 0 after freeing 2018-07-09T08:46:30Z bluhm bluhm@openbsd.org 2018-07-09T08:46:30Z urn:sha1:21c85adc82cf6f023de093b050b8ab587ea321a9 the memory in uvm. Another process could use the false 0 then. To be on the safe side, protect all access to ku_indx and ku_pagecnt with a mutex. Update ku_indx and ku_pagecnt before calling uvm_km_free(). Update ksp after uvm_km_free() to keep accounting correct. tested by sthen@; OK mpi@ visa@ deraadt@ While booting it does not make sense to wait for memory, there is 2018-01-18T18:08:51Z bluhm bluhm@openbsd.org 2018-01-18T18:08:51Z urn:sha1:a97ba27b3153adcbfb3d800439a2e57d1435f534 no other process which could free it. Better panic in malloc(9) or pool_get(9) instead of sleeping forever. tested by visa@ patrick@ Jan Klemkow suggested by kettenis@; OK deraadt@ Fix an off-by-one in the free(9) "passed size was too small" check: 2018-01-02T06:07:21Z guenther guenther@openbsd.org 2018-01-02T06:07:21Z urn:sha1:29e477084e4cf41df33525bd7f1c7464ee47f717 if the size passed is exactly half the size of the bucket that the allocation was actually from, then it was incorrect. problem noted by florian@ ok florian@ visa@