From: Dave Jones <davej@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
Joerg Roedel <joro@8bytes.org>,
Joerg Roedel <joerg.roedel@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: BUG_ON/panic proliferation.
Date: Thu, 27 Sep 2012 13:30:57 -0400 [thread overview]
Message-ID: <20120927173057.GA13142@redhat.com> (raw)
In-Reply-To: <CA+55aFx5CtDDpXTunJDtkDQWPX7sY0hYMRyekuPErC+s5yXpWw@mail.gmail.com>
On Thu, Sep 27, 2012 at 09:59:13AM -0700, Linus Torvalds wrote:
> We have too many f*cking BUG_ON's in the kernel, and the fact that one
> triggers and it has taken a month and a half without it even being
> resolved is a problem.
This has bothered me for a while.
$ rgrep BUG_ON drivers/ | wc -l
4018
$ rgrep WARN_ON drivers/ | wc -l
2415
$ rgrep panic drivers/ | wc -l
997
$ rgrep BUG_ON fs | wc -l
2792
$ rgrep WARN_ON fs | wc -l
524
$ rgrep panic fs | wc -l
381
The number of 'raw' panic calls makes me wonder if there's perhaps
a lot of people who just don't realise that BUG_ON includes a panic() call.
If we had named it PANIC_ON it would have made it more obvious that
it has more dire consequences than WARN_ON.
Every time I read a "everything locked up while I was in X" bug,
I can't help but think it was one of these.
But even without X, sometimes these are painful.
I even had to change VM_BUG_ON to use WARN instead of BUG a while ago
in my local tree, because the panic locked up the machine before
the console had a chance to finish dumping.
What would be a good way forward though ? With tens of thousands of them in tree,
auditting them one-by-one and replacing them as we go is going to take forever.
checkpatch already has a check for new additions of BUG/BUG_ON, but the
majority of patches go into the tree unchecked, so that's not particularly helpful.
Dave
next prev parent reply other threads:[~2012-09-27 17:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 13:41 kernel BUG at /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681! Joerg Roedel
2012-08-07 13:55 ` Bryan Schumaker
2012-08-07 14:15 ` Joerg Roedel
2012-08-07 14:17 ` Bryan Schumaker
2012-08-07 14:27 ` Joerg Roedel
2012-08-07 14:36 ` Bryan Schumaker
2012-08-07 14:50 ` Joerg Roedel
2012-08-07 15:12 ` Bryan Schumaker
2012-08-07 15:19 ` Myklebust, Trond
2012-08-07 15:19 ` Myklebust, Trond
2012-08-07 15:14 ` Myklebust, Trond
2012-08-07 15:14 ` Myklebust, Trond
2012-08-07 15:18 ` Bryan Schumaker
2012-09-27 14:52 ` Joerg Roedel
2012-09-27 15:32 ` Myklebust, Trond
2012-09-27 15:39 ` Joerg Roedel
2012-09-27 16:16 ` Myklebust, Trond
2012-09-27 16:16 ` Myklebust, Trond
2012-09-27 16:59 ` Linus Torvalds
2012-09-27 17:30 ` Dave Jones [this message]
2012-09-28 0:52 ` BUG_ON/panic proliferation Ryan Mallon
2012-09-28 10:08 ` Alan Cox
2012-09-27 21:21 ` kernel BUG at /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681! Myklebust, Trond
2012-09-27 21:21 ` Myklebust, Trond
2012-09-27 17:56 ` Joerg Roedel
2012-09-27 18:15 ` Bryan Schumaker
2012-09-28 12:17 ` Joerg Roedel
2012-09-28 13:21 ` Bryan Schumaker
2012-09-28 13:34 ` Joerg Roedel
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=20120927173057.GA13142@redhat.com \
--to=davej@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=joerg.roedel@amd.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 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.