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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/