about summary refs log tree commit diff
path: root/arch/x32
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2015-08-07 19:19:49 +0000
committerRich Felker <dalias@aerifal.cx>2015-08-07 19:19:49 +0000
commitc3761622e8168b0c6453637ac82e70b09af3e8e9 (patch)
tree90e92a2e312a3ad7389b53b402b1aef4b4fe1008 /arch/x32
parent3c43c0761e1725fd5f89a9c028cbf43250abb913 (diff)
downloadmusl-c3761622e8168b0c6453637ac82e70b09af3e8e9.tar.gz
musl-c3761622e8168b0c6453637ac82e70b09af3e8e9.tar.xz
musl-c3761622e8168b0c6453637ac82e70b09af3e8e9.zip
mitigate blow-up of heap size under malloc/free contention
during calls to free, any free chunks adjacent to the chunk being
freed are momentarily held in allocated state for the purpose of
merging, possibly leaving little or no available free memory for other
threads to allocate. under this condition, other threads will attempt
to expand the heap rather than waiting to use memory that will soon be
available. the race window where this happens is normally very small,
but became huge when free chooses to use madvise to release unused
physical memory, causing unbounded heap size growth.

this patch drastically shrinks the race window for unwanted heap
expansion by performing madvise with the bin lock held and marking the
bin non-empty in the binmask before making the expensive madvise
syscall. testing by Timo Teräs has shown this approach to be a
suitable mitigation.

more invasive changes to the synchronization between malloc and free
would be needed to completely eliminate the problem. it's not clear
whether such changes would improve or worsen typical-case performance,
or whether this would be a worthwhile direction to take malloc
development.
Diffstat (limited to 'arch/x32')
0 files changed, 0 insertions, 0 deletions