Re: [PATCH][IPSEC][4/6] changing "ipip tunnel" and xfrm4_tunnel to the API change

[Patrick McHardy <kaber@trash.net>]

Kazunori MIYAZAWA wrote:
> Changing ipip tunnel and xfrm4_tunnel to the API

Fixing up users after API changes should be done in the same
patch as the API change itself to avoid breaking compilation
for people doing a bisection.

> index f110af5..00fc09f 100644
> --- a/net/ipv4/xfrm4_tunnel.c
> +++ b/net/ipv4/xfrm4_tunnel.c
> @@ -66,12 +66,15 @@ static struct xfrm_tunnel xfrm_tunnel_ha
>  
>  static int __init ipip_init(void)
>  {
> -	if (xfrm_register_type(&ipip_type, AF_INET) < 0) {
> -		printk(KERN_INFO "ipip init: can't add xfrm type\n");
> +	if (xfrm_register_type(&ipip_type, AF_INET) < 0)
> +		return -EAGAIN;

Why are you removing the printk?

> +
> +	if (xfrm4_tunnel_register(&xfrm_tunnel_handler, AF_INET)) {
> +		printk(KERN_INFO "ipip init: can't add xfrm handler for AF_INET\n");
>  		return -EAGAIN;

Does not unregister ipip_type on error.

>  	}
> -	if (xfrm4_tunnel_register(&xfrm_tunnel_handler)) {
> -		printk(KERN_INFO "ipip init: can't add xfrm handler\n");
> +	if (xfrm4_tunnel_register(&xfrm_tunnel_handler, AF_INET6)) {

You register xfrm_tunnel_handler twice, which will corrupt the list.

> +		printk(KERN_INFO "ipip init: can't add xfrm handler for AF_INET6\n");
>  		xfrm_unregister_type(&ipip_type, AF_INET);

Does not unregister AF_INET tunnel handler on error.

>  		return -EAGAIN;
>  	}

The next patch has similar problems.