It appears that commit 58c5d0d6d522112577c7eeb71d382ea642ed7be4 causes another regression of allocations with MAP_32BIT. Reverting it fixes the reproducer from https://lore.kernel.org/linux-mm/cb8dc31a-fef2-1d09-f133-e9f7b9f9e77a@xxxxxxxx/ Do you think this commit is somewhat safe to revert? The following may be superfluous, but adds some context and might help someone find this thread. It merely confirms to the observation of this regression in https://lore.kernel.org/linux-mm/e6108286ac025c268964a7ead3aab9899f9bc6e9.camel@xxxxxxxxx/ From what I can tell it also fixes my own use case, and - The program I maintain, https://github.com/hercules-ci/hercules-ci-agent/issues/514 - Another program, also Haskell: https://github.com/aristanetworks/nix-serve-ng/issues/27 - An FPGA interface process. I've found them because they list the same commit id on their blog. https://jia.je/software/2023/05/06/linux-regression-vivado-en/ On 3/2/23 19:43, Liam R. Howlett wrote: > * Snild Dolkow <snild@xxxxxxxx> [230302 10:33]: >> After upgrading a machine from 5.17.4 to 6.1.12 a couple of weeks ago, I >> started getting (inconsistent) failures when building Android: >> While it claims to be using 0x22 (MAP_PRIVATE | MAP_ANONYMOUS) for the >> flags, it really uses 0x40 (MAP_32BIT) as well, as shown by strace: >> The same applies to the dynamic linker in the GHC Haskell runtime system. It also uses MAP_32BIT, in its linker, and reports the error ghc: mmap 4096 bytes at (nil): Cannot allocate memory I hope this was a somewhat useful contribution to the regressions thread. (also hi, I'm new here) Cheers, Robert Hensing
