* Robert Hensing <robert@xxxxxxxxxxxxxxx> [230511 21:02]: > 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? No, don't do that. Add this [1] instead. The patch is currently in mm-unstable and will make its way though the normal channels to stable and mainline [1] https://lore.kernel.org/linux-mm/20230505145829.74574-1-zhangpeng.00@xxxxxxxxxxxxx/ Thanks, Liam > > 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 > >
