LINUX.ORG.RU

История изменений

Исправление KivApple, (текущая версия) :

Нет гарантий, что один и тот же участок адресов будет доступен в разных адресных пространствах.

В целом что где будет занято и свободно это implementation defined от версии ядра, glibc и некоторых крутилок в системе. А с включенной рандомизацией адресов ещё и от рандома зависит.

Также есть проблема гонки потоков - технически, почти любая функция glibc может вызывать под капотом аллокацию памяти. А любая аллокация памяти это потенциальный mmap, при этом алгоритм выбора свободного адреса - implementation defined. Таким образом, даже если ты нашёл каким-то образом (например, через /proc) свободный участок, то если у тебя >1 потока в программе (а потоки могут создавать в том числе динамические библиотеки без твоего ведома), то нет гарантий, что между поиском и вызовом mmap кто-то другой не сделает mmap раньше тебя и не займёт этот адрес.

Короче, как я понял из манов, mmap с фиксированным адресом имеет смысл только для замены маппингов, которые уже существуют в процессе. Либо при написании своих загрузчиков исполняемых файлов (когда ты контролируешь всё происходящее в процессе).

Исходная версия KivApple, :

Нет гарантий, что один и тот же участок адресов будет доступен в разных адресных пространствах.

В целом что где будет занято и свободно это implementation defined от версии ядра, glibc и некоторых крутилок в системе. А с включенной рандомизацией адресов ещё и от рандома зависит.

Также есть проблема гонки потоков - технически, почти любая функция glibc может вызывать под капотом аллокацию памяти. А любая аллокация памяти это потенциальный mmap, при этом алгоритм выбора свободного адреса - implementation defined. Таким образом, даже если ты нашёл каким-то образом (например, через /proc) свободный участок, то если у тебя >1 потока в программе (а потоки могут создавать в том числе динамические библиотеки без твоего ведома), то нет гарантий, что между поиском и вызовом mmap кто-то другой не сделает mmap раньше тебя и не займёт этот адрес.