On Sun, Nov 07, 2010 at 04:16:47PM +0900, Yoshinori Sano wrote: > 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? > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
