Hi Siddhesh,

On 4/4/23 13:42, Siddhesh Poyarekar wrote:
> On 2023-04-04 01:52, Mingye Wang wrote:
>> Hi all,
>>
>> In (somewhat) recent discussions about _FORTIFY_SOURCE level 3, a
>> common snag to hit seems to be abuse of malloc_usable_size(). The
>> attached patch is my attempt at making the situation easier to sort
>> through.
>>
>> See siddhesh's comment on GitHub.[0] I wonder if the language needs to
>> be stronger.
>>    [0]: https://github.com/systemd/systemd/issues/22801#issuecomment-1343041481
> 
> For more context of my statement, please see this discussion:
> 
> https://sourceware.org/pipermail/libc-alpha/2022-November/143599.html
> 
> which continued into the next month:
> 
> https://sourceware.org/pipermail/libc-alpha/2022-December/143667.html

This might be useful to you: I happen to comaintain a code base that
uses malloc_usable_size(3).  I have no idea why it was added, and it
seems to be used in a test, but not in the actual program, which makes
me happy to not have to fix that :).  Maybe it is useful to you to check
that code to see why would some heavily-optimized code base want to use
it.  You may very well find that it was not really used for anything
useful; there's a lot of dead code which I haven't been able to remove
yet due to discrepancies.

Here are all the mentions I see to this API:

$ grep -rn malloc_usable_size
src/test/nxt_malloc_test.c:54:        nxt_malloc_usable_size(p[i], s);
src/nxt_malloc.h:37: * memory than is requested, so malloc_usable_size() allows to use all
src/nxt_malloc.h:52: * with small cutback and then to adjust size with malloc_usable_size().
src/nxt_malloc.h:53: * Glibc malloc_usable_size() is fast operation.
src/nxt_malloc.h:56:#define nxt_malloc_usable_size(p, size)                                       \
src/nxt_malloc.h:57:    size = malloc_usable_size(p)
src/nxt_malloc.h:77: * FreeBSD 7.0 malloc_usable_size() is fast for allocations, which
src/nxt_malloc.h:81:#define nxt_malloc_usable_size(p, size)                                       \
src/nxt_malloc.h:82:    size = malloc_usable_size(p)
src/nxt_malloc.h:101:#define nxt_malloc_usable_size(p, size)                                       \
src/nxt_malloc.h:108:#define nxt_malloc_usable_size(p, size)
src/nxt_unix.h:32:#include <malloc.h>                 /* malloc_usable_size(). */
src/nxt_unix.h:49:#include <malloc_np.h>              /* malloc_usable_size(). */
auto/malloc:53:# Linux malloc_usable_size().
auto/malloc:55:nxt_feature="Linux malloc_usable_size()"
auto/malloc:66:                      if (malloc_usable_size(p) < 4096)
auto/malloc:75:    # FreeBSD malloc_usable_size().
auto/malloc:77:    nxt_feature="FreeBSD malloc_usable_size()"
auto/malloc:89:                          if (malloc_usable_size(p) < 4096)

The only ones that may be interesting to you are the single use (the
commit that added the line says "Initial version.", so it won't help):

<https://github.com/nginx/unit/blob/c54331fa3d9597ba6bc85e7b7242981f00ed25c2/src/test/nxt_malloc_test.c#L54>

and the header where we define a wrapper macro, which contains several
comments about assumptions made about different libc implementations:

<https://github.com/nginx/unit/blob/c54331fa3d9597ba6bc85e7b7242981f00ed25c2/src/nxt_malloc.h#L35>

I hope that tells you something.  It doesn't tell me anything, but I'm
not used to fiddling with allocators.  :)

Cheers,
Alex


> 
> This amendment that DJ wrote is probably the most precise description of 
> the current malloc_usage_size situation:
> 
>    The value returned by malloc_usable_size() may be greater than the
>    requested size of the allocation because of various internal
>    implementation details, none of which the programmer should rely on.
>    This function is intended to only be used for diagnostics and
>    statistics; writing to the excess memory without first calling
>    realloc() to resize the allocation is not supported.  The returned
>    value is only valid at the time of the call; any other call to a
>    malloc family API may invalidate it.
> 
> Thanks,
> Sid

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5