From e1a7c721d34158f94f6b6dee94a211d32e9f5752 Mon Sep 17 00:00:00 2001 From: Jason Ekstrand Date: Wed, 23 Sep 2015 14:20:23 -0700 Subject: [PATCH] anv/allocator: Don't ever call mremap This has always been a bit sketchy and neither Kristian nor I have ever really liked it. --- src/vulkan/anv_allocator.c | 29 ++++++++++++----------------- 1 file changed, 12 insertions(+), 17 deletions(-) diff --git a/src/vulkan/anv_allocator.c b/src/vulkan/anv_allocator.c index cbd2b6d0f51..05126305b51 100644 --- a/src/vulkan/anv_allocator.c +++ b/src/vulkan/anv_allocator.c @@ -421,23 +421,18 @@ anv_block_pool_grow(struct anv_block_pool *pool, struct anv_block_state *state) goto fail; *cleanup = ANV_MMAP_CLEANUP_INIT; - /* First try to see if mremap can grow the map in place. */ - map = MAP_FAILED; - if (old_size > 0 && center_bo_offset == 0) - map = mremap(pool->map, old_size, size, 0); - if (map == MAP_FAILED) { - /* Just leak the old map until we destroy the pool. We can't munmap it - * without races or imposing locking on the block allocate fast path. On - * the whole the leaked maps adds up to less than the size of the - * current map. MAP_POPULATE seems like the right thing to do, but we - * should try to get some numbers. - */ - map = mmap(NULL, size, PROT_READ | PROT_WRITE, - MAP_SHARED | MAP_POPULATE, pool->fd, - BLOCK_POOL_MEMFD_CENTER - center_bo_offset); - cleanup->map = map; - cleanup->size = size; - } + /* Just leak the old map until we destroy the pool. We can't munmap it + * without races or imposing locking on the block allocate fast path. On + * the whole the leaked maps adds up to less than the size of the + * current map. MAP_POPULATE seems like the right thing to do, but we + * should try to get some numbers. + */ + map = mmap(NULL, size, PROT_READ | PROT_WRITE, + MAP_SHARED | MAP_POPULATE, pool->fd, + BLOCK_POOL_MEMFD_CENTER - center_bo_offset); + cleanup->map = map; + cleanup->size = size; + if (map == MAP_FAILED) goto fail; -- 2.30.2