Date: Thu, 28 Nov 2013 13:33:41 +0000 (UTC) From: jb <jb.1234abcd@gmail.com> To: freebsd-current@freebsd.org Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <loom.20131128T143120-188@post.gmane.org> References: <CA%2BhQ2%2BiNurBQnmH-4-DN9V-krc_R=dbEaznJkxLDOzkJEWpFMg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo <rizzo <at> iet.unipi.it> writes:
>
> in porting some linux kernel code to FreeBSD we
> stumbled upon ksize(), which returns the
> actual size of a kmalloc() block.
>
> We could easily implement it as the first part
> of realloc(9) -- see kern/kern_malloc.c
>
> Would it make sense to add this to the malloc(9) API ?
> The userspace equivalent seems to be
> malloc_usable_size(3) which according to the
> manpage appeared in FreeBSD 7.0
Hi,
The implementation of ksize() depends on (has non-standard behavior across)
architectures, memory allocators, page sizes, C libs, etc.
It means, ksize() exports its implementation details to the caller, and this
disqualifies it, regardless whether in kernel or user spaces.
This leads to dangerous and conflicting assertions:
malloc_usable_size(3) on Linux:
NOTES
The value returned by malloc_usable_size() may be greater than the
requested size of the allocation because of alignment and minimum size
constraints. Although the excess bytes can be overwritten by the
application without ill effects, this is not good programming practice:
the number of excess bytes in an allocation depends on the underlying
implementation.
The main use of this function is for debugging and introspection.
Other sources:
...
The caller may use this additional memory, even though a smaller amount of
memory was initially specified with the kmalloc call.
...
This is hair-raising:
http://lwn.net/Articles/319686/
Result ? The same code works here, but may not elsewhere.
It follows, you should remove malloc_usable_size() from user space instead.
jb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?loom.20131128T143120-188>