All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Antonio SJ Musumeci <trapexit@spawn.link>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>
Subject: Re: BUG_ON() in workingset_node_shadows_dec() triggers
Date: Thu, 6 Oct 2016 16:59:20 -0700	[thread overview]
Message-ID: <CA+55aFzWrHmpp54YkqaCKc-UPWm59_9AXmENNtqqgpj6zWOxsQ@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jL=0pJMx5qASXnF1zAzw2CJVvn09siLLgaFBY_57VmH-w@mail.gmail.com>

On Thu, Oct 6, 2016 at 4:05 PM, Kees Cook <keescook@chromium.org> wrote:
>
> It seems to handle other things too, file descriptors, I think? Some
> giant warning, I think about fds, went away when I switched from
> do_exit() to BUG(). I'd have to go look more closely.

I think you must have changed something else too. I can't think of
what else there is than the crazy "oops_in+_progress" hacks. We used
to reset the preempt counter too, but with that being per-thread I
don't think that even matters.

So I think you may have some voodoo programming there.

An an oops (but not a do_exit()) will add a taint, and there's the
notifications that might do random things (mainly kgdb and tracing).
But that should be pretty much it.

> Yeah, for sure. I didn't mean to imply they all depended on it, just
> that finding those that do will require manual inspection. We'll not
> be able to do a flag-day on BUG until we fix everything.

Not true. That kind of thinking just says "we can never change BUG at all".

You'll never fix anything that way.

We should just switch BUG() over and be done with it. The whole point
it that since it should never trigger in the first place, the
semantics on BUG() should never matter.

And if you have some code that depends on the semantics of BUG(), that
code is buggy crap *by*definition*.

And there's no way we'll let that kind of shit determine kernel
development. That would be insane.

                Linus

  reply	other threads:[~2016-10-06 23:59 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04  4:00 BUG_ON() in workingset_node_shadows_dec() triggers Linus Torvalds
2016-10-04  4:07 ` Andrew Morton
2016-10-04  4:12   ` Linus Torvalds
2016-10-04  7:03     ` Raymond Jennings
2016-10-04 16:03       ` Linus Torvalds
2016-10-04  8:02 ` Greg KH
2016-10-04  9:32 ` Johannes Weiner
2016-10-05  1:21   ` Linus Torvalds
2016-10-05  9:25     ` Johannes Weiner
2016-10-05  9:31       ` Johannes Weiner
2016-10-05 10:40       ` Jan Kara
2016-10-05 16:10       ` Linus Torvalds
2016-10-05 17:00         ` [PATCH] checkpatch: extend BUG warning Joe Perches
2016-10-05 17:00           ` Joe Perches
2016-10-05 17:07           ` Linus Torvalds
2016-10-05  2:43 ` BUG_ON() in workingset_node_shadows_dec() triggers Paul Gortmaker
2016-10-05  3:29   ` Linus Torvalds
2016-10-05  5:44     ` Willy Tarreau
2016-10-05 15:52       ` Linus Torvalds
2016-10-05 19:06         ` Willy Tarreau
2016-10-05 19:18           ` Linus Torvalds
2016-10-05 21:09             ` Willy Tarreau
2016-10-05 21:14             ` Kees Cook
2016-10-05 21:46               ` Linus Torvalds
2016-10-05 22:17                 ` Kees Cook
2016-10-05 22:29                   ` Linus Torvalds
2016-10-06 22:07                     ` Kees Cook
2016-10-06 22:29                       ` Linus Torvalds
2016-10-06 23:05                         ` Kees Cook
2016-10-06 23:59                           ` Linus Torvalds [this message]
2016-10-07  5:48                             ` Willy Tarreau
2016-10-07 17:16                               ` Kees Cook
2016-10-07 17:21                                 ` Linus Torvalds
2016-10-07 17:33                                   ` Kees Cook
2016-10-07 18:26                                     ` Willy Tarreau
2016-10-06  1:59     ` Dave Chinner
2016-10-06  2:12       ` Linus Torvalds

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=CA+55aFzWrHmpp54YkqaCKc-UPWm59_9AXmENNtqqgpj6zWOxsQ@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=paul.gortmaker@windriver.com \
    --cc=stable@vger.kernel.org \
    --cc=trapexit@spawn.link \
    --cc=w@1wt.eu \
    /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.