Re: [PATCH] release_resource() check for NULL resource

[Al Viro <viro@ftp.linux.org.uk>]

On Mon, Oct 03, 2005 at 03:43:50PM +0300, Pekka Enberg wrote:
> On 10/3/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > 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?
> 
> Usually yes but it makes releasing partial initialization much simpler
> because you can  reuse the normal release counterpart. For example,
> 
> static int driver_init(void)
> {
>      dev->resource1 = request_region(...);
>      if (!dev->resource1)
>              goto failed;
> 
>      dev->resource2 = request_region(...);
>      if (!dev->resource2)
>              goto failed;
> 
>      return 0;
> 
> failed:
>      driver_release(dev);
>      return -1;
> }
> 
> static void driver_release(struct device * dev)
> {
>      release_resource(dev->resource1);
>      release_resource(dev->resource2);
>      kfree(dev);
> }
> 
> Many drivers have the release function copy-pasted to init with lots
> of goto labels exactly because release_region, iounmap, and friends
> aren't NULL safe.

Bullshit.  I have waded through many, *many* initialization sequences
like that.  "Lots of goto labels" is _less_ prone to breakage when
properly done; your variant begs for trouble upon the driver changes.

Note that "lots of goto" is actually a cleaner control structure than
what you propose - the amount of instances of offending statement is
far from being the only metrics.  The only things to verify with it are
	* releasing is done in the opposite order to claiming
	* you always exit to the releasing the last thing you've claimed.
Both are easy to maintain when you change the code _and_ do not break
when you need to introduce something like "keep the number of objects";
I've seen too many cases when release had done the things that can _not_
be made idempotent and still had been used in that manner.  With obvious
breakage resulting from it.

And such breakage is easily introduced when changing the code - it's more
common than forgetting to propagate change between release and failure
exits in initialization.
-
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/