wireguard-openbsd/libexec/ld.so/malloc.c, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/libexec/ld.so/malloc.c?h=jd%2Fqueueboosts 2019-09-30T03:35:09Z Oops: the call to ofree() in orealloc() was misconverted into a call to 2019-09-30T03:35:09Z guenther guenther@openbsd.org 2019-09-30T03:35:09Z urn:sha1:8d5943eb3f53949662f0b6540057c931297cd1fe _dl_free(), which would trigger a "recursive call" assertion...if we had ever realloced in ld.so ok deraadt@ ld.so's malloc has no runtime option processing, so remove the 2018-11-02T07:26:25Z otto otto@openbsd.org 2018-11-02T07:26:25Z urn:sha1:133128c465770436f69611503e391c542d150732 setting flags and replace them by constants. ok deraadt@ guenther@ Delay processing of ld.so's own PT_GNU_RELRO section until after environment 2018-10-23T04:01:45Z guenther guenther@openbsd.org 2018-10-23T04:01:45Z urn:sha1:d1b0fb8fb3a964323473438f43f47e69e73ece83 processing and malloc initialization, and then move variables set by those steps, including malloc's mopts structure, into the .data.rel.ro segment. This protects more data and eliminates the extra padding of the mopts. ok kettenis@ sync with libc malloc: use consistent style for for loop in unmap(), 2018-02-07T18:59:20Z otto otto@openbsd.org 2018-02-07T18:59:20Z urn:sha1:2b5a45926ba632471019e2784d01cc24f42b0746 no functional change don't forget to increment loop var; infinite loops spotted by sthen@ 2018-02-01T11:14:23Z otto otto@openbsd.org 2018-02-01T11:14:23Z urn:sha1:5efa8d23cee8c96ff4ee9b1e4219568e485251f6 kill a gcc warning 2018-01-30T17:45:53Z otto otto@openbsd.org 2018-01-30T17:45:53Z urn:sha1:bf73d255909e66a699ad0afa26112f7f7a1679c1 port over the malloc changes from libc. prompted by deraadt@ 2018-01-30T16:40:20Z otto otto@openbsd.org 2018-01-30T16:40:20Z urn:sha1:8ddaed9efb31018a55f8e9fff7ec3c2eec7abfa8 Redo the calculation of the alignment and placement of static TLS data to 2017-12-01T23:30:05Z guenther guenther@openbsd.org 2017-12-01T23:30:05Z urn:sha1:f54aa4647fbcdf3cdb61745d141e42ecec60a7ae correctly take into account the segment p_align. Previously, anything with a size belong the natural alignment or with alignment larger than the natural one would either not be intialized correctly, be misaligned, or result in the TIB being misaligned. Problems reported by Charles Collicutt (charles (at) collicutt.co.uk) ok kettenis@ Sync with libc malloc, doing delayed free double-free check always 2017-10-05T09:34:57Z otto otto@openbsd.org 2017-10-05T09:34:57Z urn:sha1:59be94969b6a2000c1687d15386b7081cbc38835 from libc malloc: only access offset if canaries are enabled *and* size > 0 2017-07-23T09:36:16Z otto otto@openbsd.org 2017-07-23T09:36:16Z urn:sha1:ab22d9a3435f5310e98dc86a7649765fd6cf17a8 and initialize ->offset to a definite value in the size == 0 case