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

From: David Chisnall <theraven_at_FreeBSD.org>
Date: Fri, 29 Nov 2013 11:16:01 +0000
On 28 Nov 2013, at 15:13, jb <jb.1234abcd_at_gmail.com> wrote:

> Luigi Rizzo <rizzo <at> iet.unipi.it> writes:
> 
>> ... 
>> But I don't understand why you find ksize()/malloc_usable_size() dangerous.
>> ...
> 
> The original crime is commited when *usable size* (an implementation detail)
> is exported (leaked) to the caller.
> To be blunt, when a caller requests memory of certain size, and its request is
> satisfied, then it is not its business to learn details beyond that (and they
> should not be offered as well).
> The API should be sanitized, in kernel and user space.
> Otherwise, all kind of charlatans will try to play hair-raising games with it.
> If the caller wants to track the *requested size* programmatically, it is its
> business to do it and it can be done very easily.
> 
> Some of these guys got it perfectly right:
> http://stackoverflow.com/questions/5813078/is-it-possible-to-find-the-memory-allocated-to-the-pointer-without-searching-fo

I disagree.  I've encountered several occasions where either locality doesn't matter so much or I know the pointer is aliased, and I'd like increase the size of a relatively large allocation.  I have two choices:

- Call realloc(), potentially copying a lot of data
- Call malloc(), and chain two (or more) allocations together.

What I'd like to do is call realloc() if it's effectively free, or call malloc() in other cases.

The malloc_useable_size() API is wrong though.  In the kernel, realloc() already takes a flag and a M_DONTALLOCATE would make more sense, enlarging the allocation if it can be done without doing the allocate-copy-free dance, but returning NULL and leaving the allocation unmodified if not.

David
Received on Fri Nov 29 2013 - 10:16:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC