Messages in this thread | | | Date | Mon, 3 Oct 2005 19:15:42 -0700 | From | "Randy.Dunlap" <> | Subject | Re: [PATCH] release_resource() check for NULL resource |
| |
On Mon, 3 Oct 2005 11:04:31 +0100 Russell King wrote:
> On Mon, Oct 03, 2005 at 11:59:01AM +0200, Jesper Juhl wrote: > > On 10/3/05, Ben Dooks <ben-linux@fluff.org> wrote: > > > On Sun, Oct 02, 2005 at 10:39:22AM -0700, Randy.Dunlap wrote: > > > > On Sun, 2 Oct 2005 18:03:18 +0100 Ben Dooks wrote: > > > > > > > > > If release_resource() is passed a NULL resource > > > > > the kernel will OOPS. > > > > > > > > does this actually happen? you are fixing a real oops? > > > > if so, what driver caused it? > > > > > > I was developing a couple of new drivers, and found > > > that this does not behave like kfree() which does check > > > for NULL paramemters. I belive it would be helpful if > > > functions like this followed the example of kfree(). > > > > > I would agree that it makes sense for resource release functions to be > > written defensively and be able to cope with being passed a NULL > > resource, just like kfree(), vfree(), crypto_free_tfm() and others are > > already doing. > > Seems safer and allows us to get rid of checks for NULL before calling > > such functions thus making code simpler, more readable and in some > > cases smaller. > > I'm not convinced - release_resource() isn't like kfree() - it's more > like device_unregister(). > > It makes sense for kfree() to ignore NULL pointers, but does it really > make sense for *_unregister() to do so too? Surely you want to only > unregister things which you know have previously been registered?
I agree. The driver should know the state of such registrations or allocations and act accordingly. Having foo_release() check its parameter before acting on it just encourages sloppy programming. kfree() is an exception IMO, not the rule.
--- ~Randy You can't do anything without having to do something else first. -- Belefant's Law - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |