Re: [patches] malloc & madvise

[Richard Kralovic <Richard.Kralovic@xxxxxxxxxxx>]

> I have a couple of questions about handling of free_blocks.  Here is the 
> definition:
> 
> struct free_block {
>    /* Lenght of the block */
>    INTERNAL_SIZE_T size;
> 
>    /* Circular doubly linked list within the chunk. */
>    struct free_block *bk_chunk, *fd_chunk;
> 
>    /* Circular doubly linked list of blocks sorted by creation time. */
>    struct free_block *bk_time, *fd_time;
> };
> 
> /* End of the given free_block. */
> #define BLOCK_END(p) ((void *)(p) + (p)->size)
> 
> 1. You're assuming the fact that nothing else in malloc uses free()d 
> chunks, so you're hosting free_block nodes in that space.  I'm a bit 
> worried about how safe this approach is.

I am quite confident that the interior of free()d chunks is never used
by malloc: When malloc() is called (function public_mALLOc() in
malloc.c), it handles threading/locking (no way to access freed()
chunks) and calls _int_malloc(). Here, when a free chunk is found, it is
returned as available to the application without any modifications of
its interior. Hence, the interior can not hold any data valuable to
malloc itself. Besides, I have not found any code accessing interior of
free()d chunks in the malloc application at all.

> 2. Some architectures have certain alignment requirements for 
> structures, so is it the case that free()d chunks will have appropriate 
> alignment to host a structure at the beginning?

struct free_block is used to

1) hold head/tail pointers in struct malloc_state and struct
malloc_chunk. Here, compiler should take care about all necessary
alignments.

malloc_state is allocated at the beginning of heaps, and proper
alignment for the following data is handled at arena.c:930.

2) represent the nodes of the linked lists. These are always aligned to
page boundaries, so alignment should not be a problem.

Greets
	Richard