All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Willy Tarreau <w@1wt.eu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	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: Fri, 7 Oct 2016 10:16:42 -0700	[thread overview]
Message-ID: <CAGXu5jLTo+QY9YuEKYbACXdnAXgnQdPPnPejYtiSeg4j5XW-Fw@mail.gmail.com> (raw)
In-Reply-To: <20161007054824.GA9917@1wt.eu>

On Thu, Oct 6, 2016 at 10:48 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Oct 06, 2016 at 04:59:20PM -0700, Linus Torvalds wrote:
>> 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*.
>
> I totally agree with this. If a developer writes BUG() somewhere, it
> means he doesn't see how it is possible to end up in this situation.
> Thus we cannot hope that the BUG() call is doing anything right to
> fix what the code author didn't expect to happen. It just means
> "try to limit the risks but I don't really know which ones".
>
> Also we won't make things worse. Where people currently have an oops,
> they'll get one or more warnings. The side effects (lockups, panic,
> etc) will more or less be the same, but many of us already don't want
> to continue after an oops and despite this our systems work fine, so
> I don't see why anyone would suffer from such a change. However some
> developers may get more details about issues than what they could get
> in the past.

Fair enough. I'll put something together for at least my use-cases and
see how ugly it gets in testing. :) I actually started on something
like this for the CONFIG_DEBUG_LIST, which had to deal with the logic
of "continue after WARN or abort after BUG" etc...

Regardless, I still think that we can't let BUG continue kernel
execution though, since it may lead to entirely unexpected behavior
(possibly security-sensitive) by still running. Upgrading BUG to
panic(), though, I'd be fine with, as a way to get people to convert
to WARN.

-Kees

-- 
Kees Cook
Nexus Security

  reply	other threads:[~2016-10-07 17:16 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
2016-10-07  5:48                             ` Willy Tarreau
2016-10-07 17:16                               ` Kees Cook [this message]
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=CAGXu5jLTo+QY9YuEKYbACXdnAXgnQdPPnPejYtiSeg4j5XW-Fw@mail.gmail.com \
    --to=keescook@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=paul.gortmaker@windriver.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.