summaryrefslogtreecommitdiff
path: root/arch/Kconfig
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2024-06-17 22:57:03 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2024-06-17 22:57:03 +0300
commit14d7c92f8df9c0964ae6f8b813c1b3ac38120825 (patch)
treed17ba0d273178bceeaec8ebcbcd9cf2a4f6fc958 /arch/Kconfig
parente6b324fbf2de1797a4756fe2a489442464738dad (diff)
downloadlinux-14d7c92f8df9c0964ae6f8b813c1b3ac38120825.tar.xz
Revert "mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default"
This reverts commit 3afb76a66b5559a7b595155803ce23801558a7a9. This was a wrongheaded workaround for an issue that had already been fixed much better by commit 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment on 32 bit"). Asking users questions at kernel compile time that they can't make sense of is not a viable strategy. And the fact that even the kernel VM maintainers apparently didn't catch that this "fix" is not a fix any more pretty much proves the point that people can't be expected to understand the implications of the question. It may well be the case that we could improve things further, and that __thp_get_unmapped_area() should take the mapping randomization into account even for 64-bit kernels. Maybe we should not be so eager to use THP mappings. But in no case should this be a kernel config option. Cc: Rafael Aquini <aquini@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/Kconfig')
-rw-r--r--arch/Kconfig12
1 files changed, 0 insertions, 12 deletions
diff --git a/arch/Kconfig b/arch/Kconfig
index 3e2a63772b3d..975dd22a2dbd 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1046,21 +1046,10 @@ config ARCH_MMAP_RND_BITS_MAX
config ARCH_MMAP_RND_BITS_DEFAULT
int
-config FORCE_MAX_MMAP_RND_BITS
- bool "Force maximum number of bits to use for ASLR of mmap base address"
- default y if !64BIT
- help
- ARCH_MMAP_RND_BITS and ARCH_MMAP_RND_COMPAT_BITS represent the number
- of bits to use for ASLR and if no custom value is assigned (EXPERT)
- then the architecture's lower bound (minimum) value is assumed.
- This toggle changes that default assumption to assume the arch upper
- bound (maximum) value instead.
-
config ARCH_MMAP_RND_BITS
int "Number of bits to use for ASLR of mmap base address" if EXPERT
range ARCH_MMAP_RND_BITS_MIN ARCH_MMAP_RND_BITS_MAX
default ARCH_MMAP_RND_BITS_DEFAULT if ARCH_MMAP_RND_BITS_DEFAULT
- default ARCH_MMAP_RND_BITS_MAX if FORCE_MAX_MMAP_RND_BITS
default ARCH_MMAP_RND_BITS_MIN
depends on HAVE_ARCH_MMAP_RND_BITS
help
@@ -1095,7 +1084,6 @@ config ARCH_MMAP_RND_COMPAT_BITS
int "Number of bits to use for ASLR of mmap base address for compatible applications" if EXPERT
range ARCH_MMAP_RND_COMPAT_BITS_MIN ARCH_MMAP_RND_COMPAT_BITS_MAX
default ARCH_MMAP_RND_COMPAT_BITS_DEFAULT if ARCH_MMAP_RND_COMPAT_BITS_DEFAULT
- default ARCH_MMAP_RND_COMPAT_BITS_MAX if FORCE_MAX_MMAP_RND_BITS
default ARCH_MMAP_RND_COMPAT_BITS_MIN
depends on HAVE_ARCH_MMAP_RND_COMPAT_BITS
help