If kore_realloc() decides that a new block must be allocated it will
explicitly call the new kore_free_zero() function to erase the
contents of the old block once the move is done.
When KORE_MEM_GUARD is set in the environment when Kore is started
it will enable a few memory protection techniques for all kore pools:
1) The metadata is placed away from the actual user pointer returned.
2) Each entry in a pool is placed in such a way that it is followed
immediately by a guard page which has PROT_NONE. Accessing a guard
page will cause an immediate crash.
3) Each entry is marked with PROT_NONE until it is allocated. Once it
is returned to a pool it becomes PROT_NONE again, protecting against
use after frees.
This commit also removes the magic goo from the mem facitilies such
as kore_malloc and friends and moves these as canaries into the kore
pool facilities instead.
Note that using this will increase memory pressure and decrease performance.
It is recommended to enable this during development to catch bugs.
use it in places explicit_bzero() used to be called.
The kore_mem_zero() is a best effort to try and let the compiler
not optimize the code away. Highly platform dependent.
This allows modules that have global pointers to upon reload repopulate
those with the addresses of when they were first created.
Meaning it now is easier to write modules that can be reloaded if those
modules kept global state one way or the other.
This should only be used at module init/reload time and is very simple:
if ((ptr = kore_mem_lookup(MY_ID_VALUE)) == NULL) {
ptr = kore_malloc_tagged(length, MY_ID_VALUE);
/* initialize for the first time. */
}
If we were in a reload the kore_mem_lookup() will return the original address
returned by the initial kore_malloc_tagged() call for MY_ID_VALUE.
We were not returning zeroed out memory from kore_calloc() which goes
against what calloc() does. Skip performance for now and simply just
memset() the returned pointer from kore_malloc().
This should be sufficient enough for now.
we just increase the lenght requested to 8 bytes if we get a 0 byte request.
additionally when kore_realloc() is called check if we actually have
to do the work, if not just return the original pointer.
- Change pools to use mmap() for allocating regions.
- Change kore_malloc() to use pools for commonly sized objects.
(split into multiple of 2 buckets, starting at 8 bytes up to 8192).
- Rename kore_mem_free() to kore_free().
The preallocated pools will hold up to 128K of elements per block size.
In case a larger object is to be allocated kore_malloc() will use
malloc() instead.
Make it return the original length of the input string so the caller
can check for truncation. Also guard against len being 0 as this would
not do anything with the destination string (not even NUL terminate it).
This basically turns off the HTTP layer for Kore. It does not
compile in anything for HTTP.
This allows Kore to be used as a network application platform as well.
Added an example for this called nohttp.
Other changes that sneaked in while hacking on this:
* Use calloc(), kill pendantic malloc option.
* Killed off SPDY/3.1 support completely, will be superseded by http2
Note that comes with massive changes to a lot of the core API
functions provided by Kore, these might break your application.
- Introduce own memory management system on top of malloc to keep track
of all our allocations and free's. Later we should introduce a pooling
mechanism for fixed size allocations (http_request comes to mind).
- Introduce ssl_cipher in configuration.
Memory usage is kind of high right now, but it seems its OpenSSL
doing it rather then Kore.
- Introduce own memory management system on top of malloc to keep track
of all our allocations and free's. Later we should introduce a pooling
mechanism for fixed size allocations (http_request comes to mind).
- Introduce ssl_cipher in configuration.
Memory usage is kind of high right now, but it seems its OpenSSL
doing it rather then Kore.
Joris Vink
Stig Telfer