On Lunes 19 Octubre 2009 12:36:13 Andi Drebes escribió: > However, is there any interest in patches fixing these problems? If yes: what > would be the best strategy? Should we start fixing this "layer by layer" -- > the low-level functions first and the high-level functions later on? Or > should use come kind of "vertical approach" -- one low-level function and all > of its callers at once?
I don't know what is the developer plan to fix that - apparently it's not in the high-priority list (but it must be certainly in the priority list, anyone who gets out of memory using btrfs will have some chances of getting an oops - but notice that most of the important paths are ready to handle errors reliably and there aren't many bug reports due to bad oom handling, so it doesn't seems to be that critical). I realized that it isn't really helpful to add BUG_ONs to failed allocation paths, the code will oops itself as soon as it tries to use the NULL pointer, so adding BUG_ONs is redundant. Passing the error to the callers and handling all that properly is the real fix, but since it requires auditing the whole FS it's probably not an easy task. I tried to do that with a couple of functions, but Kleen's mail made me realize that it isn't that easy. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
