From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
Rafael Aquini <aquini@redhat.com>,
Jiri Slaby <jirislaby@kernel.org>,
Suren Baghdasaryan <surenb@google.com>
Cc: linux-mm@kvack.org, mm-commits@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] hotfixes for 6.10-rc5
Date: Mon, 17 Jun 2024 13:09:15 -0700 [thread overview]
Message-ID: <CAHk-=wjiUzOHfHaWgUcByAygaG6w_BKOqbTN6EHrDHaXb_i+xA@mail.gmail.com> (raw)
In-Reply-To: <20240617114712.45d4743f8bacb832dea4b5a9@linux-foundation.org>
On Mon, 17 Jun 2024 at 11:47, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Rafael Aquini (1):
> mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default
No.
And HELL NO!
We're not adding *another* new random incomprehensible config option
that tries to fix a random case that no normal user will understand.
Our kernel config is too damn complex as-is. We're not making it worse
like this. Anybody who cares about this kind of crazy esoteric detail
can damn well just set their Kconfig manually, instead of forcing this
kind of insane questions on other people.
This Kconfig insanity needs to stop. Why do I need to be the person who says
"STOP ASKING POOR USERS IDIOTIC QUESTIONS THAT THEY CAN'T SANELY ANSWER"
I've pulled, but I'm reverting this commit. We are *not* going down
this path of insanity.
I'd also like to note that the reported 32-bit issue was ALREADY FIXED
months ago by commit 4ef9ad19e176 ("mm: huge_memory: don't force huge
page alignment on 32 bit")
It's possible that we should extend that - much saner - fix to also
look at the number of bits for randomization even outside of 32-bit
processes, and judge things on the number of bits we're expected to
randomize mappings on.
So it's very possible that the
if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
return 0;
test in __thp_get_unmapped_area() should be extended to take requested
address randomization into account.
But there is NO WAY this is fixed with another completely
incomprehensible Kconfig option.
So I'm really unhappy about this. The whole "add idiotic random
Kconfig options" needs to stop.
Those options are not something a normal person can understand, and as
shown by the fact that this patch was already bogus and superseded by
a much better patch from months ago, clearly said Kconfig options
WEREN'T EVEN UNDERSTOOD BY VM MAINTAINERS!
Christ. Sorry for the shouting, but dammit, people need to really
internalize the whole "we don't add crazy Kconfig options".
Linus
next prev parent reply other threads:[~2024-06-17 20:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 18:47 Andrew Morton
2024-06-17 20:09 ` Linus Torvalds [this message]
2024-06-17 20:17 ` Matthew Wilcox
2024-06-17 20:23 ` Linus Torvalds
2024-06-17 20:20 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wjiUzOHfHaWgUcByAygaG6w_BKOqbTN6EHrDHaXb_i+xA@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=aquini@redhat.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mm-commits@vger.kernel.org \
--cc=surenb@google.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox