mmap implementation for ANON mapping with desired address

[Alexander Tormasov]

Can anyone help the question below about "additional efforts to trace and delete something else"?


> 12 авг. 2020 г., в 02:07, Alexander Tormasov via users <users at lists.genode.org> написал(а):
> 
> I am trying to implement not-yet supported (as mentioned by nfeske@ in mailing list) option 
> for mmap() related to anonymous mapping with pre-defined (desired) address.
> Like libc function with  desired address out_addr.
>   void *Libc::Mem_alloc_impl::alloc_at(void *out_addr, size_t size)
> 
> I use a couple of useful function in avl allocator. Anyway, I found that straight - forward 
> implementation do not work because of allocation gaps filled together with main allocation.
> 
> In particular, if we want to allocate e.g. 0x10000 from address 0x500000 then we
> typically allocate 0x13000 bytes, including ones for avl metadata/etc stored in the same
> space, and receive virtual address range used, e.g. 0x500000 - 0x513000:
> 
>    /*
>     * Calculate block size of needed backing store. The block must hold the
>     * requested 'size' with the requested alignment, a new Dataspace structure
>     * and space for AVL-node slab blocks if the allocation above failed.
>     * Finally, we align the size to a 4K page.
>     */
>    size_t request_size = size + max((1 << align_log2), 1024) +
>                          Allocator_avl::slab_block_size() + sizeof(Dataspace);
> 
> Software I used (golang runtime) sometimes try to expand previous allocation, e.g. it can
> request allocation of 0x8000 bytes before previous range, like 0x4f8000 - 0x500000.
> In that case I can’t perform the operation - because it will try to allocate 0xa000 bytes from 
> desired address 0x4f8000 - and it obviously fail due to Range_conflict.
> 
> So, I split allocation to 2 parts - one for this gap by standard alloc() and random placement
> and second one by my own alloc_at() with size exactly correspond to the requested one.
> 
> Implementation available as a patch to 20.05 at
> 
> https://github.com/tor-m6/genode/commit/78fc751bea8acc2b515e04bec9f3a883461510c7
> 
> Problem I see here is a free operation: it just free the block with requested address, and do
> not touch others, gap-related blocks. For me it is not obvious that they need to be free,
> because in the code (e.g. by unmap()) I do not see explicit free of other allocated structures,
> in particular, dataspace extension or related block metadata.
> 
> Question: should I make additional efforts to trace and delete something else - except what
> standard free does here:
>    /* forward request to our local allocator */
>    _alloc.free(addr);
> 
> Like for dataspace structure or address ranges for second «auxiliary» allocation?
> 
> PS Another potential problem is a probability to overlap of first «random address» allocation with
> desired address. This happens with first attempt to implement allocator - it allocates address
> from desired range, and immediately put here 0x18 bytes of Dataspace structure, and then fail
> because requested address is already busy by this structure! Anyway, I consider such a 
> probability relatively small with proposed approach and ignore it (may be I am wrong)
> 
> 
> 
> 
> _______________________________________________
> Genode users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users