All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <greg@kroah.com>, <linux-usb-devel@lists.sourceforge.net>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.5.34
Date: Mon, 9 Sep 2002 18:41:06 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0209091832160.1714-100000@home.transmeta.com> (raw)
In-Reply-To: <1031618439.31787.20.camel@irongate.swansea.linux.org.uk>


On 10 Sep 2002, Alan Cox wrote:
> 
> I'd have thought you may well want the reverse. If the user didnt pick
> the kernel debugging, don't die on software check option you want to
> blow up.

No, thanks. If it's fatal, it's a BUG(), and you blow regardless.

If it isn't fatal, there is no excuse for blowing up. EVER.  That's
_especially_ true for some random user who didn't ask for, and can't
handle debugging. If it's useful information that the developer believes
he wants, it shouldn't be conditional at all.

> If they are debugging or its < 2.6.0-rc1 you want it to show
> the stack and keep going

You definitely want to keep going regardless. A BUG() that takes out the
machine is just not useful, because users who aren't ready to debug it
can't even make any reports except "it stops" (which this one did if you
were under X - the machine was just _dead_).

Basically, with the amount of locking we have, a BUG() or a blow-up just 
about anywhere is lethal. Most sequences (especially in drivers, but 
inside filesystems etc too) tend to hold spinlocks etc that just makes it 
a bad idea to BUG() out unless you really really have to, since the 
machine is not likely to survive and be able to write good reports to disk 
etc at pretty much any point.

(It used to be that you could take a fault just about anywhere except for
in interrupt handlers, and Linux would try its damndest to clean up and
continue as if nothing had happened. Those days are sadly gone, and
trapping and depending on killing the process seldom works well any more).

On the whole, it's a lot better to just print out a message (and call
traces are often very useful) and continue. That's not always possible, of
course, and a lot of BUG() and BUG_ON() cases are perfectly valid simply
because sometimes there isn't anything you can do except kill the machine
and try to inform the user.

I think the historical kernel behaviour ("trap and kill and continue"  
historically worked so fine for _both_ major bugs and for "random sanity
test" cases) has caused us to be a bit lazy about this sometimes.

			Linus


  reply	other threads:[~2002-09-10  1:36 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-09 22:17 [BK PATCH] USB changes for 2.5.34 Greg KH
2002-09-10  0:17 ` Linus Torvalds
2002-09-10  0:19   ` Greg KH
2002-09-10  0:30     ` Linus Torvalds
2002-09-10  0:40       ` [linux-usb-devel] " Alan Cox
2002-09-10  1:41         ` Linus Torvalds [this message]
2002-09-10  1:48           ` Linus Torvalds
2002-09-10 10:23     ` Andries Brouwer
2002-09-10  0:35   ` Nicholas Miell
2002-09-10  1:01     ` [patch] dump_stack(): arch-neutral stack trace Andrew Morton
2002-09-15  4:34       ` Daniel Phillips
2002-09-15  4:51         ` Andrew Morton
2002-09-10  1:27     ` [BK PATCH] USB changes for 2.5.34 Linus Torvalds
2002-09-10  2:07   ` Matthew Dharm
2002-09-10  2:49     ` Linus Torvalds
2002-09-10  2:59       ` Linus Torvalds
2002-09-10 16:32       ` [linux-usb-devel] " David Brownell
2002-09-10 16:51         ` Linus Torvalds
2002-09-10 17:16           ` Jeff Garzik
2002-09-10 18:16             ` David S. Miller
2002-09-10 18:40               ` Linus Torvalds
2002-09-10 18:48                 ` Jeff Garzik
2002-09-10 19:31                 ` David S. Miller
2002-09-10 19:32                 ` Oliver Xymoron
2002-09-10 19:38                   ` Linus Torvalds
2002-09-10 19:43                     ` Jeff Garzik
2002-09-10 21:52                   ` Bill Davidsen
2002-09-10 22:02                     ` Jeff Garzik
2002-09-10 18:44           ` Alan Cox
2002-09-10 19:03             ` Linus Torvalds
2002-09-10 19:27               ` Rik van Riel
2002-09-10 20:18                 ` Alan Cox
2002-09-10 22:00                 ` David Woodhouse
2002-09-10 22:23                   ` Alan Cox
2002-09-10 22:26                   ` David Woodhouse
2002-09-10 23:01                     ` Alan Cox
2002-09-10 19:29               ` David S. Miller
2002-09-15  5:10               ` Daniel Phillips
2002-09-15  5:33                 ` Daniel Berlin
2002-09-15 16:41                   ` Daniel Phillips
2002-09-16  0:32                     ` Horst von Brand
2002-09-15  6:07                 ` Pete Zaitcev
2002-09-15  7:00                   ` Andrew Morton
2002-09-15 14:53                   ` Daniel Phillips
2002-09-15 18:23                     ` Pete Zaitcev
2002-09-15 18:34                       ` Jeff Garzik
2002-09-16  0:55                         ` Larry McVoy
2002-09-15 20:05                   ` David Woodhouse
2002-09-15 21:35                   ` Rob Landley
2002-09-16  3:00                     ` Larry McVoy
2002-09-16  3:08                       ` Daniel Phillips
2002-09-16 11:16                       ` Henning P. Schmiedehausen
2002-09-16 18:35                       ` Thunder from the hill
2002-09-16 18:45                         ` Daniel Phillips
2002-09-16 19:36                           ` Thunder from the hill
2002-09-16 19:40                             ` Daniel Phillips
2002-09-16  8:50                     ` Ian Molton
2002-09-16  9:37                       ` Rob Landley
2002-09-15 18:06                 ` Linus Torvalds
2002-09-15 18:36                   ` Roman Zippel
2002-09-15 19:04                   ` Daniel Jacobowitz
2002-09-15 19:43                     ` Andrew Morton
2002-09-15 19:43                       ` Daniel Phillips
2002-09-15 23:24                     ` Larry McVoy
2002-09-15 23:41                       ` Daniel Jacobowitz
2002-09-15 23:52                         ` Larry McVoy
2002-09-16  0:01                           ` Robert Love
2002-09-16  1:29                           ` Alan Cox
2002-09-16  2:13                             ` Larry McVoy
2002-09-16 11:05                               ` Henning P. Schmiedehausen
2002-09-16 14:05                               ` Rogier Wolff
2002-09-16 16:24                               ` Marco Colombo
2002-09-16  0:44                       ` Daniel Phillips
2002-09-16  1:23                       ` Alan Cox
2002-09-15 19:07                   ` Daniel Phillips
2002-09-16  9:06                     ` Jens Axboe
2002-09-16 15:15                       ` Daniel Phillips
2002-09-16 15:59                         ` kernel debuggers was [Re: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.5.34] Soewono Effendi
2002-09-16 14:14                     ` [linux-usb-devel] Re: [BK PATCH] USB changes for 2.5.34 David Woodhouse
2002-09-16 14:53                       ` Jens Axboe
2002-09-15 19:08                   ` Linus Torvalds
2002-09-15 19:10                     ` Daniel Phillips
2002-09-15 19:26                       ` Linus Torvalds
2002-09-15 19:32                         ` Daniel Jacobowitz
2002-09-15 19:48                           ` Daniel Phillips
2002-09-16  4:59                             ` Jeff Dike
2002-09-16  4:05                               ` Daniel Phillips
2002-09-16  4:55                           ` Jeff Dike
2002-09-15 19:35                         ` Daniel Phillips
2002-09-16  4:51                       ` Jeff Dike
2002-09-16 15:29                     ` Oliver Xymoron
2002-09-18  0:33                   ` Rusty Russell
2002-09-18  0:46                     ` Linus Torvalds
2002-09-18  0:50                       ` Daniel Phillips
2002-09-18  1:16                         ` Rik van Riel
2002-09-15 13:54               ` Rogier Wolff
2002-09-15  5:01           ` Daniel Phillips
2002-09-10 16:46       ` Thunder from the hill
2002-09-10 16:56         ` Vojtech Pavlik

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=Pine.LNX.4.44.0209091832160.1714-100000@home.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    /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.