Re: Proper error handling on NULL pointers

[Diego Calleja <diegocg@gmail.com>]

On Lunes 19 Octubre 2009 12:36:13 Andi Drebes escribi=C3=B3:
> However, is there any interest in patches fixing these problems? If y=
es: what would be the best strategy? Should we start fixing this "layer=
 by layer" -- the low-level functions first and the high-level function=
s later on? Or should use come kind of "vertical approach" -- one low-l=
evel 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 alloca=
tion
paths, the code will oops itself as soon as it tries to use the NULL po=
inter,
so adding BUG_ONs is redundant. Passing the error to the callers and ha=
ndling
all that properly is the real fix, but since it requires auditing the w=
hole FS
it's probably not an easy task. I tried to do that with a couple of fun=
ctions,
but Kleen's mail made me realize that it isn't that easy.=20
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html