From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>, Kees Cook <keescook@chromium.org>,
Jann Horn <jannh@google.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH] mm/tlb: Fix use_mm() vs TLB invalidate
Date: Fri, 21 Feb 2020 11:26:29 -0800 [thread overview]
Message-ID: <CAHk-=whDHsbK3HTOpTF=ue_o04onRwTEaK_ZoJp_fjbqq4+=Jw@mail.gmail.com> (raw)
In-Reply-To: <6A09F721-0AD9-4B86-AB3E-563A1CF5ABDE@amacapital.net>
On Fri, Feb 21, 2020 at 11:22 AM Andy Lutomirski <luto@amacapital.net> wrote:
>
> In this particular case, if we actually flub this, we are very likely to cause data corruption — we’re about to do user access with the wrong mm.
So?
IF this ever triggers, it has presumably been around for decades.
Nobody noticed.
Adding a WARN_ON_ONCE() means that somebody will now notice. Good.
Adding a BUG_ON() will now possibly mean that the machine is dead, and
is not sending the bug-report to anybody.
It's not going to hit, of course. But if you are 100% sure of that,
then it shouldn't exist at all.
And if you're not 100% sure of it, then it's going to be in some very
unusual circumstances (possibly some odd driver subsystem that does
something completely wrong - wouldn't be the first time), and the last
thing you want to do is lose the information about it.
So BUG_ON() is basically ALWAYS 100% the wrong thing to do. The
argument that "there could be memory corruption" is complete and utter
garbage. See above why.
Stop it. Seriously.
Linus
next prev parent reply other threads:[~2020-02-21 19:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 11:11 [PATCH] mm/tlb: Fix use_mm() vs TLB invalidate Peter Zijlstra
2020-02-21 19:19 ` Linus Torvalds
2020-02-21 19:22 ` Andy Lutomirski
2020-02-21 19:26 ` Linus Torvalds [this message]
2020-02-21 23:10 ` Kees Cook
2020-02-21 23:57 ` Linus Torvalds
2020-02-22 0:29 ` Kees Cook
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-=whDHsbK3HTOpTF=ue_o04onRwTEaK_ZoJp_fjbqq4+=Jw@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=peterz@infradead.org \
--cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).