From: Arnd Bergmann <arnd@xxxxxxxx>
MAP_UNINITIALIZED was added back in 2009 for NOMMU kernels, specifically
for blackfin, which is long gone. MAP_HUGE_SHIFT/MAP_HUGE_MASK were
added in 2012 for architectures supporting hugepages, which at the time
did not overlap with the ones supporting NOMMU.
Adding the macro under an #ifdef was obviously a mistake, which
Christoph Hellwig tried to address by making it unconditionally defined
to 0x4000000 as part of the series to support RISC-V NOMMU kernels. At
this point linux/mman.h contained two conflicting definitions for bit 26,
though the two are still mutually exclusive at runtime in all supported
configurations.
According to the commit 854e9ed09ded ("mm: support madvise(MADV_FREE)")
description, it was previously used internally by facebook, which
would have resulted in MAP_HUGE_1MB turning into MAP_HUGE_2MB
with MAP_UNINITIALIZED enabled, and every other page size implying
MAP_UNINITIALIZED. I assume there are no remaining out of tree users
on MMU-enabled kernels today.
I do not see any sensible way to redefine the macros for the ABI in
a way avoids breaking something. The only ideas so far are:
- do nothing, try to document the bug, hope for the best
- remove the kernel implementation and redefine MAP_UNINITIALIZED to
zero in the header to silently turn it off for everyone. There are
few NOMMU users left, and the ones that do use NOMMU usually turn
off MMAP_ALLOW_UNINITIALIZED, as it still has the potential to cause
bugs and even security issues on systems with a memory protection
unit.
- remove both the implementation and the macro to force a build
failure for anyone trying to use the feature. This way we can
see who complains and whether we need to put it back in some
form or change the userspace sources to no longer pass the flag.
Implement the third option here for the sake of discussion.