LinuxカーネルHack: BtrfsのBUG_ONマクロ撲滅運動

以前のエントリーで、BtrfsにBUG_ONマクロが散見されることについて書いた。この件について、#btrfsのIRCチャネルでBUG_ONについて質問してみた。でも、IRCではほしい答えが得られなかったので、Btrfsの開発メーリングリストに質問を投げてみた。

On Removing BUG_ON macros

http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg06664.html

This is a question I've posted on the #btrfs IRC channel today.
hyperair adviced me to contact with Josef Bacik or Chris Mason.
So, I post my question to this maling list.

Here are my post on the IRC:

Actually, I want to remove BUG_ON(ret) around the Btrfs code.
The motivation is to make the Btrfs code more robust.
First of all, is this meaningless?

For example, there are code like the following:

    struct btrfs_path *path;
    path = btrfs_alloc_path();
    BUG_ON(!path);

This is a frequenty used pattern of current Btrfs code.
A btrfs_alloc_path()'s caller has to deal with the allocation failure
instead of using BUG_ON.  However, (this is what most interesting
thing for me) can the caller do any proper error handlings here?
I mean, is this a critical situation where we cannot recover from?

-- 
Yoshinori Sano <yoshinori.s...@gmail.com>

Re: On Removing BUG_ON macros

そしたら、Josefさんから返事が来た。単にlazyだと。。どんな風に返事しようかな。

http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg06666.html

No we're just lazy ;).  Tho making sure the caller can recover from getting
-ENOMEM is very important, which is why in some of these paths we just do BUG_ON
since fixing the callers is tricky.  A good strategy for things like this is to
do something like

static int foo = 1;

path = btrfs_alloc_path();
if (!path || !(foo % 1000))
        return -ENOMEM;
foo++;

that way you can catch all the callers and make sure we're handling the error
all the way up the chain properly.  Thanks,

Josef