linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Tejun Heo <htejun@gmail.com>,
	Louis Langholtz <lou_langholtz@me.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Trivial patch monkey <trivial@kernel.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce CRASH_ON()
Date: Mon, 08 Jun 2015 11:22:03 +0200	[thread overview]
Message-ID: <55755EBB.7020105@ahsoftware.de> (raw)
In-Reply-To: <20150608091132.GA19566@gmail.com>

Am 08.06.2015 um 11:11 schrieb Ingo Molnar:
>
> * Ingo Molnar <mingo@kernel.org> wrote:
>
>> Firstly, the changelog of the patch that Greg rejected told nothing about all
>> that thinking, so at minimum it's a deficient changelog.
>>
>> Secondly and more importantly, instead of doing a BUG_ON() you could have done:
>>
>> 	if (WARN_ON_ONCE(port->itty))
>> 		return;
>>
>> This would probably have prevented the tty related memory corruption just as
>> much, at the cost of a (small and infrequent) memory leak.
>>
>> I.e. instead of crashing the machine, you need to try to find the least
>> destructive approach if a bug is detected.
>
> Also note that BUG_ON() will make data corruption _worse_ statistically. Why?
> Because most data corruptions are unlikely to be perfectly detected by a BUG_ON(),
> and the BUG_ON() delays the finding of the underlying bug, so the bug will hit
> more people before it's fixed for good.
>
> So even in the cases where you could argue that the system needs to stop, because
> we have evidence of data corruption, it's statistically the better approach to
> continue and get kernel log info back to developers.

Risking more, maybe even worse problems like corrupting file systems or 
similiar in order to have a slightly chance of save log info?

Sorry, that isn't something I would propose.

Anyway, CRASH_ON didn't exist, so I only had the choice between BUG_ON 
and WARN_ON, and for the latter you need a proper exit path which isn't 
always easy to find. So I appreciate CRASH_ON, thanks.

Alexander Holler

  reply	other threads:[~2015-06-08  9:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <http://marc.info/?l=linux-kernel&m=143351431301630>
2015-06-07 23:54 ` [PATCH] kernel/params.c: make use of unused but set variable Louis Langholtz
2015-06-08  0:00   ` Tejun Heo
2015-06-08  0:17     ` Linus Torvalds
2015-06-08  0:58       ` Tejun Heo
2015-06-08  5:24         ` [PATCH v2] " Louis Langholtz
2015-06-10 17:05         ` [PATCH] " Louis Langholtz
2015-06-11  1:54           ` Tejun Heo
2015-06-12  3:17             ` Louis Langholtz
2015-06-08  5:44       ` [PATCH] checkpatch: Warn on BUG and BUG_ON uses Joe Perches
2015-06-08  5:46       ` [PATCH] kernel/params.c: make use of unused but set variable Louis Langholtz
2015-06-08  7:12       ` [PATCH] debug: Deprecate BUG_ON() use in new code, introduce CRASH_ON() Ingo Molnar
2015-06-08  7:40         ` Alexander Holler
2015-06-08  8:08           ` Richard Weinberger
2015-06-08  8:42             ` Alexander Holler
2015-06-08  9:05               ` Ingo Molnar
2015-06-08  9:11                 ` Ingo Molnar
2015-06-08  9:22                   ` Alexander Holler [this message]
2015-06-08 11:29                     ` Ingo Molnar
2015-06-08  9:16                 ` Alexander Holler
2015-06-08 11:27                   ` Ingo Molnar
2015-06-08 18:07                     ` Alexander Holler
2015-06-08 19:35                       ` Ingo Molnar
2015-06-09  1:07                         ` Alexander Holler
2015-06-08  8:09           ` Ingo Molnar
2015-06-12  1:27       ` [PATCH] kernel/params.c: make use of unused but set variable Rusty Russell
2015-06-12  1:48         ` Tejun Heo
2015-06-14 19:49           ` Rusty Russell
2015-06-16 19:54             ` Tejun Heo
2015-06-08 14:26 [PATCH] debug: Deprecate BUG_ON() use in new code, introduce CRASH_ON() Alexey Dobriyan

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=55755EBB.7020105@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=htejun@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lou_langholtz@me.com \
    --cc=mingo@kernel.org \
    --cc=richard.weinberger@gmail.com \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=trivial@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).