History log of /openbsd-src/sys/kern/kern_malloc.c (Results 1 – 25 of 153)
Revision Date Author Comments
# ffff71aa 14-Jan-2025 mvs <mvs@openbsd.org>

Unlock sysctl_malloc().

Move `buckstring' and `memall' strings initialization to the end of
kmeminit() to make them immutable. The rest of sysctl_malloc() accessed
data is already mp-safe.

ok claud

Unlock sysctl_malloc().

Move `buckstring' and `memall' strings initialization to the end of
kmeminit() to make them immutable. The rest of sysctl_malloc() accessed
data is already mp-safe.

ok claudio

show more ...


# da5607f6 26-Jun-2024 jsg <jsg@openbsd.org>

return type on a dedicated line when declaring functions
ok mglocker@


# d6514e0f 14-Dec-2023 claudio <claudio@openbsd.org>

Workaround for broken clang which has a broken -fno-zero-initialized-in-bss
implementation.

Set nkmempages to -1 by default instead of 0 so that the value ends up in
the data section. This way confi

Workaround for broken clang which has a broken -fno-zero-initialized-in-bss
implementation.

Set nkmempages to -1 by default instead of 0 so that the value ends up in
the data section. This way config(8) is able to alter the value as promised.

See also: https://github.com/llvm/llvm-project/issues/74632
OK miod@

show more ...


# ca803f33 14-Dec-2023 claudio <claudio@openbsd.org>

Bring default logic to set nkmempages into the 21st century.

The new logic is:
Up to 1G physmem use physical memory / 4,
above 1G add an extra 16MB per 1G of memory.

Clamp it down depending on avai

Bring default logic to set nkmempages into the 21st century.

The new logic is:
Up to 1G physmem use physical memory / 4,
above 1G add an extra 16MB per 1G of memory.

Clamp it down depending on available kernel virtual address space
- up and including 512M -> 64MB (macppc, arm, sh)
- between 512M and 1024M -> 128MB (hppa, i386, mips, luna88k)
- over 1024M clamping to VM_KERNEL_SPACE_SIZE / 4

The result is much more malloc(9) space on 64bit archs with lots of memory
and large kva space.
Note: amd64 only has 4G of kva and therefor nkmempages is limited to 262144

As a side-effect NKMEMPAGES_MAX and nkmempages_max are no longer used.
Tested and OK miod@

show more ...


# f4810b03 29-Nov-2023 claudio <claudio@openbsd.org>

Cleanup kmeminit_nkmempages().

NKMEMPAGES_MIN was removed long time ago in all archs so there is no
need to keep it.
Also initalize nkmempages_max at compile time since sparc (with variable
page siz

Cleanup kmeminit_nkmempages().

NKMEMPAGES_MIN was removed long time ago in all archs so there is no
need to keep it.
Also initalize nkmempages_max at compile time since sparc (with variable
page size) is long gone as well.
No objection from miod@

show more ...


# 0d280c5f 14-Aug-2022 jsg <jsg@openbsd.org>

remove unneeded includes in sys/kern
ok mpi@ miod@


# feb3ff6b 04-May-2022 bluhm <bluhm@openbsd.org>

Introduce mutex for ratecheck(9) and ppsratecheck(9). A global
mutex with spl high for all function calls is used for now. It
protects the lasttime and curpps parameter. This solution is MP
safe f

Introduce mutex for ratecheck(9) and ppsratecheck(9). A global
mutex with spl high for all function calls is used for now. It
protects the lasttime and curpps parameter. This solution is MP
safe for the usual use case, allows progress, and can be optimized
later. Remove a useless #if 1 while there.
OK claudio@

show more ...


# 4123b6a7 16-May-2021 deraadt <deraadt@openbsd.org>

panic does not require a \n at the end. When one is provided, it looks wrong.


# 388a5417 21-Apr-2021 mpi <mpi@openbsd.org>

Convert remaining uvm_km_zalloc(9) to km_alloc(9).

Tested by bluhm@, jj@, kettenis@ and Scott Bennett.

ok kettenis@


# e587a465 23-Feb-2021 jsg <jsg@openbsd.org>

remove unused malloc_roundup()


# 48eb9f4d 31-Dec-2020 claudio <claudio@openbsd.org>

Add trace points for malloc(9) and free(9). This makes them traceable
via dt(4) and btrace(8).
OK mpi@ millert@


# 957017e2 14-Oct-2020 deraadt <deraadt@openbsd.org>

delete strange historical FFS_SOFTUPDATES ifdef...
ok millert


# babb761d 19-Dec-2019 mpi <mpi@openbsd.org>

Convert infinite sleeps to {m,t}sleep_nsec(9).

ok visa@


# 610978bc 28-Nov-2019 guenther <guenther@openbsd.org>

Delete km_mapblocks from kmemstats and its always-zero column from the ddb
"show malloc" output

ok deraadt@ mpi@


# d3ca6102 15-May-2019 tedu <tedu@openbsd.org>

rework the zero warning slightly, and more completely disable until we're
more ready to deal with the noise.


# 2dec572b 09-May-2019 tedu <tedu@openbsd.org>

disable stack printing for now since at least arm64 can't print them
reported by kettenis


# 5cb55026 08-May-2019 tedu <tedu@openbsd.org>

print a few warnings when calling free with a zero size.
let's see what falls out.
ok beck deraadt kettenis mpi


# 4120fcf0 10-Jul-2018 bluhm <bluhm@openbsd.org>

In free(9) call wakeup() after mtx_leave() consistently.
OK kettenis@ visa@ mpi@


# 5c57e1c5 09-Jul-2018 bluhm <bluhm@openbsd.org>

Fix trailing whitespaces and too long line.


# 21c85adc 09-Jul-2018 bluhm <bluhm@openbsd.org>

Make free(9) MP safe. It was wrong to set ku_indx to 0 after freeing
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_pag

Make free(9) MP safe. It was wrong to set ku_indx to 0 after freeing
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@

show more ...


# a97ba27b 18-Jan-2018 bluhm <bluhm@openbsd.org>

While booting it does not make sense to wait for memory, there is
no other process which could free it. Better panic in malloc(9)
or pool_get(9) instead of sleeping forever.
tested by visa@ patrick@

While booting it does not make sense to wait for memory, there is
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@

show more ...


# 29e47708 02-Jan-2018 guenther <guenther@openbsd.org>

Fix an off-by-one in the free(9) "passed size was too small" check:
if the size passed is exactly half the size of the bucket that the
allocation was actually from, then it was incorrect.

problem no

Fix an off-by-one in the free(9) "passed size was too small" check:
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@

show more ...


# 4c380d4e 14-Nov-2017 dlg <dlg@openbsd.org>

remove MALLOC_DEBUG

the code has rotted, and obviously hasnt been used for ages. it is
also hard to make mpsafe. if we need something like this again it
would be better to do it from scratch.

ok te

remove MALLOC_DEBUG

the code has rotted, and obviously hasnt been used for ages. it is
also hard to make mpsafe. if we need something like this again it
would be better to do it from scratch.

ok tedu@ visa@

show more ...


# 7282a73c 10-Jul-2017 dlg <dlg@openbsd.org>

make malloc(9) mpsafe by using a mutex instead of splvm.

this is almost a straightforward change of spl ops with mutex ops,
except the accounting has been shuffled around. memory is counted
as used

make malloc(9) mpsafe by using a mutex instead of splvm.

this is almost a straightforward change of spl ops with mutex ops,
except the accounting has been shuffled around. memory is counted
as used before an attempt to allocate it from uvm is made to prevent
overcommitting memory. this is modelled on how pools limit allocations.

the uvm bits have been eyeballed by kettenis@ who says they should be safe.
visa@ found some nits which have been fixed.

tested by chris@ and amit kulkarni
ok kettenis@ visa@ mpi@

show more ...


# 1a582ed7 07-Jun-2017 mpi <mpi@openbsd.org>

Assert that the calling CPU is holding the KERNEL_LOCK() in malloc(9)
and free(9).

The exception is at early boot when only one CPU is running since we
grab the KERNL_LOCK() relatively late in main(

Assert that the calling CPU is holding the KERNEL_LOCK() in malloc(9)
and free(9).

The exception is at early boot when only one CPU is running since we
grab the KERNL_LOCK() relatively late in main().

ok kettenis@

show more ...


1234567