linux-kernel - BUG_ON/panic proliferation.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120927173057.GA13142@redhat.com>
Date:	Thu, 27 Sep 2012 13:30:57 -0400
From:	Dave Jones <davej@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Myklebust, Trond" <Trond.Myklebust@...app.com>,
	Joerg Roedel <joro@...tes.org>,
	Joerg Roedel <joerg.roedel@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: BUG_ON/panic proliferation.

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

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