[php-src] PR #23554: ext/opcache: keep huge page remap inside the reserved range

From: Date: Thu, 03 Sep 2026 13:22:19 +0000
Subject: [php-src] PR #23554: ext/opcache: keep huge page remap inside the reserved range
Groups: php.git-pulls 
Request: Send a blank email to git-pulls+get-38280@lists.php.net to get a copy of this message
Pull Request: https://github.com/php/php-src/pull/23554 Author: s2x Hi, We moved our dev machines from Docker Desktop to Colima and Podman on Apple Silicon. Some of our images are amd64 only, so we turned on Rosetta 2. After that php-fpm started to crash: exit 139, one second after start, no log and no error. The same happens on Podman with Rosetta, and on Podman with QEMU. First I thought this is a Rosetta or Colima problem. It is reported like that here: https://github.com/abiosoft/colima/issues/1452 . But then I saw the same crash with QEMU, so I started to look at PHP. In create_segments() OPcache reserves memory with MAP_32BIT, frees it, moves the address up to the 2 MB boundary, and then maps requested_size again with MAP_FIXED. The address goes up, but the size stays the same. So the new mapping ends up to 2 MB above the memory we reserved, and MAP_FIXED deletes what is mapped there. Other places do this correctly. zend_mm_chunk_alloc_int() in Zend/zend_alloc.c reserves size + alignment - REAL_PAGE_SIZE first, so its aligned address always stays inside its own memory. And find_prefered_mmap_base(), in this same file, aligns the address and then checks it: if last_candidate + requested_size does not fit any more, it moves one huge page down. Here I do not see either of these. My patch reserves one huge page more. I am not sure this is the right fix, or the right place for it. It fixes the crash for us, and on native Linux with huge pages OPcache still gets its 2 MB mapping. Can somebody with more experience please look at this? I have a test script and logs if that is useful.

« previous php.git-pulls (#38280) next »