Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1160734

Re: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce CRASH_ON()

From Ingo Molnar <mingo@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce CRASH_ON()
Date 2015-06-08 21:40 +0200
Message-ID <pzb3Q-8tx-15@gated-at.bofh.it> (permalink)
References (5 earlier) <pz0UN-1Jp-7@gated-at.bofh.it> <pz1e9-2mm-17@gated-at.bofh.it> <pz1nQ-2xQ-13@gated-at.bofh.it> <pz3pE-5vv-5@gated-at.bofh.it> <pz9EJ-6vU-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


* Alexander Holler <holler@ahsoftware.de> wrote:

> Am 08.06.2015 um 13:27 schrieb Ingo Molnar:
> >
> >* Alexander Holler <holler@ahsoftware.de> wrote:
> >
> >>>I am pretty certain that Greg would have applied such a patch in an eye blink.
> >>
> >>As you've said it, *probably*. But such a simple exit path as you're proposing
> >>doesn't always exist. [...]
> >
> >As I said it's case by case. I discussed your example (which was a deficient patch
> >for multiple reasons) but we'd be wasting everyone's time by discussion
> >hypothethical situations.
> 
> Sure it was a deficient patch, but still better than what existed for a year 
> long in the kernel [...]

... but it was still worse than the simple solution I suggested:

	if (WARN_ON_ONCE(port->itty))
		return;

again, the BUG_ON() you wanted to introduce was wrong on multiple grounds, then 
and now. Why are you still arguing about this?

> I just want to make clear that a brutforce slogan like BUG_ON is bad is bad,

I pointed out specific cases where a BUG_ON() is the right solution. They are 
rare. Stop misrepresenting my words.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH] kernel/params.c: make use of unused but set variable Tejun Heo <htejun@gmail.com> - 2015-06-08 02:10 +0200
  Re: [PATCH] kernel/params.c: make use of unused but set variable Linus Torvalds <torvalds@linux-foundation.org> - 2015-06-08 02:20 +0200
    Re: [PATCH] kernel/params.c: make use of unused but set variable Tejun Heo <htejun@gmail.com> - 2015-06-08 03:00 +0200
      Re: [PATCH] kernel/params.c: make use of unused but set variable Tejun Heo <htejun@gmail.com> - 2015-06-11 04:00 +0200
        Re: [PATCH] kernel/params.c: make use of unused but set variable Louis Langholtz <lou_langholtz@me.com> - 2015-06-12 05:20 +0200
    Re: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce  CRASH_ON() Ingo Molnar <mingo@kernel.org> - 2015-06-08 13:30 +0200
    Re: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce  CRASH_ON() Ingo Molnar <mingo@kernel.org> - 2015-06-08 13:30 +0200
      Re: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce  CRASH_ON() Ingo Molnar <mingo@kernel.org> - 2015-06-08 21:40 +0200
    Re: [PATCH] kernel/params.c: make use of unused but set variable Tejun Heo <htejun@gmail.com> - 2015-06-12 03:50 +0200
      Re: [PATCH] kernel/params.c: make use of unused but set variable Tejun Heo <htejun@gmail.com> - 2015-06-16 22:00 +0200
    Re: [PATCH] kernel/params.c: make use of unused but set variable Rusty Russell <rusty@rustcorp.com.au> - 2015-06-12 03:50 +0200

csiph-web