2010/11/8 Josef Bacik <josef@xxxxxxxxxx>: > On Mon, Nov 08, 2010 at 10:17:50PM +0900, Yoshinori Sano wrote: >> To reduce the number of such BUG_ON usages, the code will be more robust, >> which results in increasing the number of Btrfs production use. >> (This is one of the way, off course.) >> >> But, as you pointed out, removing such BUG_ONs is tricky... >> >> > static int foo = 1; >> > >> > path = btrfs_alloc_path(); >> > if (!path || !(foo % 1000)) >> > return -ENOMEM; >> > foo++; >> >> Is this a debugging idiom? >> I cannot understand why this idiom can be used to catch all the callers. >> Would you explain more about it? >> > > So this forces us to return the error case every 1000 times the function is > called. So you can run various tests that stress the FS in different ways so > you can catch alot of the possible ways you can end up in this function. Then > if any of the callers have problems getting ENOMEM then the box will panic or > something like that and you can fix the callers. Then when the system stops > panicing/blowing up after a while you know you are pretty OK with returning > ENOMEM in this case and you can post the patch and move on to the next one. > > But as Ian says it gets a little confusing in the more complicated cases, so you > are probably better off walking up the possible callchains by hand and fixing > any problems you see, and then doing the above to validate your work. Thanks, Thank you for your explanation. You mean, this is a validation technique that emulates memory allocation failure repeatedly and is very useful when the paths of an interesting function's caller are spread (unclear). Thank you, -- Yoshinori Sano <yoshinori.sano@xxxxxxxxx> -- 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
