diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2024-06-17 22:57:03 +0300 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2024-06-27 14:52:32 +0300 |
commit | 095dfd9b452f543a45f28464811c0e26e2c0d3b4 (patch) | |
tree | be2a6df7b3613db9534dfef6f3923e2a29105089 /.get_maintainer.ignore | |
parent | 5c117d5936ca7a271437f3d9eee0fce65edaca2c (diff) | |
download | linux-095dfd9b452f543a45f28464811c0e26e2c0d3b4.tar.xz |
Revert "mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default"
commit 14d7c92f8df9c0964ae6f8b813c1b3ac38120825 upstream.
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to '.get_maintainer.ignore')
0 files changed, 0 insertions, 0 deletions