Re: [RFC] how to get the size of a malloc(9) block ?

On Thu, Nov 28, 2013 at 01:33:41PM +0000, jb wrote:
> 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.

This is the same exact text we have in the FreeBSD manpage,
and exactly the behaviour of ksize() in the linux kernel
(and exactly the semantics that our realloc(9) relies upon).

While I personally prefer that applications call realloc() directly,
there might be cases where the decision is best left to the application
(or kernel code): e.g. say you would like to get some extra space,
but would rather do without it than risk a malloc() failure or
having to sleep for the allocation.

And there is also a (minor) issue of portability of code.

But I don't understand why you find ksize()/malloc_usable_size() dangerous.

Of course the result depends on the underlying implementation,
but this happens in a ton of places including compiler behaviour
and system calls.
The danger is when the programmer makes assumptions that do not match
reality, but the purpose of this call seems to be exactly the opposite:
avoid making assumptions.

cheers
luigi