All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	stable@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Peter Xu <peterx@redhat.com>, Hugh Dickins <hughd@google.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	John Hubbard <jhubbard@nvidia.com>,
	Jason Gunthorpe <jgg@nvidia.com>
Subject: Re: [PATCH v1] mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW
Date: Tue, 9 Aug 2022 11:59:45 -0700	[thread overview]
Message-ID: <CAHk-=wg40EAZofO16Eviaj7mfqDhZ2gVEbvfsMf6gYzspRjYvw@mail.gmail.com> (raw)
In-Reply-To: <1a48d71d-41ee-bf39-80d2-0102f4fe9ccb@redhat.com>

On Tue, Aug 9, 2022 at 11:45 AM David Hildenbrand <david@redhat.com> wrote:
>
> I totally agree with BUG_ON ... but if I get talked to in all-caps on a
> Thursday evening and feel like I just touched the forbidden fruit, I
> have to ask for details about VM_BUG_ON nowadays.
>
> VM_BUG_ON is only active with CONFIG_DEBUG_VM. ... which indicated some
> kind of debugging at least to me. I *know* that Fedora enables it and I
> *know* that this will make Fedora crash.

No.

VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally no
different, the only difference is "we can make the code smaller
because these are less important".

The only possible case where BUG_ON can validly be used is "I have
some fundamental data corruption and cannot possibly return an error".

This kind of "I don't think this can happen" is _never_ an excuse for it.

Honestly, 99% of our existing BUG_ON() ones are completely bogus, and
left-over debug code that wasn't removed because they never triggered.
I've several times considered just using a coccinelle script to remove
every single BUG_ON() (and VM_BUG_ON()) as simply bogus. Because they
are pure noise.

I just tried to find a valid BUG_ON() that would make me go "yeah,
that's actually worth it", and couldn't really find one. Yeah, there
are several ones in the scheduler that make me go "ok, if that
triggers, the machine is dead anyway", so in that sense there are
certainly BUG_ON()s that don't _hurt_.

But as a very good approximation, the rule is "absolutely no new
BUG_ON() calls _ever_". Because I really cannot see a single case
where "proper error handling and WARN_ON_ONCE()" isn't the right
thing.

Now, that said, there is one very valid sub-form of BUG_ON():
BUILD_BUG_ON() is absolutely 100% fine.

                Linus

  reply	other threads:[~2022-08-09 19:12 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-08  7:32 [PATCH v1] mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW David Hildenbrand
2022-08-08 16:02 ` David Hildenbrand
2022-08-09 18:27 ` Linus Torvalds
2022-08-09 18:45   ` David Hildenbrand
2022-08-09 18:59     ` Linus Torvalds [this message]
2022-08-09 19:07       ` Jason Gunthorpe
2022-08-09 19:21         ` Linus Torvalds
2022-08-09 21:16         ` David Laight
2022-08-11  7:13       ` [PATCH] sched/all: Change BUG_ON() instances to WARN_ON() Ingo Molnar
2022-08-11 20:43         ` Linus Torvalds
2022-08-11 21:28           ` Matthew Wilcox
2022-08-11 23:22             ` Jason Gunthorpe
2022-08-14  1:10               ` John Hubbard
2022-08-12  9:29           ` [PATCH v2] sched/all: Change all BUG_ON() instances in the scheduler to WARN_ON_ONCE() Ingo Molnar
2022-08-15 14:41             ` Mel Gorman
2022-08-15 22:12               ` John Hubbard
2022-08-16  9:40                 ` Mel Gorman
2022-08-21 11:28               ` Ingo Molnar
2022-08-22  8:40                 ` Mel Gorman
2022-08-12  9:57         ` [tip: sched/urgent] " tip-bot2 for Ingo Molnar
2022-08-09 18:40 ` [PATCH v1] mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW Linus Torvalds
2022-08-09 18:48   ` Jason Gunthorpe
2022-08-09 18:53     ` David Hildenbrand
2022-08-09 19:07     ` Linus Torvalds
2022-08-09 19:20       ` David Hildenbrand
2022-08-09 18:48 ` Linus Torvalds
2022-08-09 19:09   ` David Hildenbrand
2022-08-09 20:00 ` Linus Torvalds
2022-08-09 20:06   ` David Hildenbrand
2022-08-09 20:07   ` David Hildenbrand
2022-08-09 20:14     ` Linus Torvalds
2022-08-09 20:20       ` David Hildenbrand
2022-08-09 20:30         ` Linus Torvalds
2022-08-09 20:38           ` Linus Torvalds
2022-08-09 20:42           ` David Hildenbrand
2022-08-09 20:20       ` Linus Torvalds
2022-08-09 20:23         ` David Hildenbrand

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-=wg40EAZofO16Eviaj7mfqDhZ2gVEbvfsMf6gYzspRjYvw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=david@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hughd@google.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.