Patchwork netfilter: ipvs: Verify that IP_VS protocol has been registered

login
register
mail settings
Submitter Sasha Levin
Date April 5, 2012, 11:24 p.m.
Message ID <1333668273-8873-1-git-send-email-levinsasha928@gmail.com>
Download mbox | patch
Permalink /patch/151018/
State Superseded
Headers show

Comments

Simon Horman - April 5, 2012, 11:19 p.m.
On Thu, Apr 05, 2012 at 07:24:33PM -0400, Sasha Levin wrote:
> The registration of a protocol might fail, there were no checks
> and all registrations were assumed to be correct. This lead to
> NULL ptr dereferences when apps tried registering.

Thanks, I will queue up this fix.

Do you have a real-world example of this failing, if so it
might be worth pushing your change into stable.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sasha Levin - April 5, 2012, 11:24 p.m.
The registration of a protocol might fail, there were no checks
and all registrations were assumed to be correct. This lead to
NULL ptr dereferences when apps tried registering.

For example:

[ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
[ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
[ 1293.227038] CPU 1
[ 1293.227038] Pid: 19609, comm: trinity Tainted: G        W    3.4.0-rc1-next-20120405-sasha-dirty #57
[ 1293.227038] RIP: 0010:[<ffffffff822aacb0>]  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] RSP: 0018:ffff880038c1dd18  EFLAGS: 00010286
[ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
[ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
[ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
[ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
[ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
[ 1293.227038] FS:  00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
[ 1293.227038] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
[ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
[ 1293.227038] Stack:
[ 1293.227038]  ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
[ 1293.227038]  ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
[ 1293.227038]  0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
[ 1293.227038] Call Trace:
[ 1293.227038]  [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
[ 1293.227038]  [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
[ 1293.227038]  [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
[ 1293.227038]  [<ffffffff821c9060>] ops_init+0x80/0x90
[ 1293.227038]  [<ffffffff821c90cb>] setup_net+0x5b/0xe0
[ 1293.227038]  [<ffffffff821c9416>] copy_net_ns+0x76/0x100
[ 1293.227038]  [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
[ 1293.227038]  [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
[ 1293.227038]  [<ffffffff810afd1f>] sys_unshare+0xff/0x290
[ 1293.227038]  [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 1293.227038]  [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
[ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
[ 1293.227038] RIP  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038]  RSP <ffff880038c1dd18>
[ 1293.227038] CR2: 0000000000000018
[ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
[ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
 net/netfilter/ipvs/ip_vs_proto.c |   21 ++++++++++++++++-----
 1 files changed, 16 insertions(+), 5 deletions(-)
Sasha Levin - April 6, 2012, 9:07 a.m.
On Fri, Apr 6, 2012 at 1:19 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Apr 05, 2012 at 07:24:33PM -0400, Sasha Levin wrote:
>> The registration of a protocol might fail, there were no checks
>> and all registrations were assumed to be correct. This lead to
>> NULL ptr dereferences when apps tried registering.
>
> Thanks, I will queue up this fix.
>
> Do you have a real-world example of this failing, if so it
> might be worth pushing your change into stable.

The scenario is a failed allocation in register_ip_vs_proto_netns(),
which can happen in real world cases as well.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - April 11, 2012, 11:22 p.m.
On Thu, Apr 05, 2012 at 07:24:33PM -0400, Sasha Levin wrote:
> The registration of a protocol might fail, there were no checks
> and all registrations were assumed to be correct. This lead to
> NULL ptr dereferences when apps tried registering.
> 
> For example:
> 
> [ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> [ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
> [ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
> [ 1293.227038] CPU 1
> [ 1293.227038] Pid: 19609, comm: trinity Tainted: G        W    3.4.0-rc1-next-20120405-sasha-dirty #57
> [ 1293.227038] RIP: 0010:[<ffffffff822aacb0>]  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038] RSP: 0018:ffff880038c1dd18  EFLAGS: 00010286
> [ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
> [ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
> [ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
> [ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
> [ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
> [ 1293.227038] FS:  00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
> [ 1293.227038] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
> [ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
> [ 1293.227038] Stack:
> [ 1293.227038]  ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
> [ 1293.227038]  ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
> [ 1293.227038]  0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
> [ 1293.227038] Call Trace:
> [ 1293.227038]  [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
> [ 1293.227038]  [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
> [ 1293.227038]  [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
> [ 1293.227038]  [<ffffffff821c9060>] ops_init+0x80/0x90
> [ 1293.227038]  [<ffffffff821c90cb>] setup_net+0x5b/0xe0
> [ 1293.227038]  [<ffffffff821c9416>] copy_net_ns+0x76/0x100
> [ 1293.227038]  [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
> [ 1293.227038]  [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
> [ 1293.227038]  [<ffffffff810afd1f>] sys_unshare+0xff/0x290
> [ 1293.227038]  [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 1293.227038]  [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
> [ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
> [ 1293.227038] RIP  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038]  RSP <ffff880038c1dd18>
> [ 1293.227038] CR2: 0000000000000018
> [ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
> [ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
> 
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> ---
>  net/netfilter/ipvs/ip_vs_proto.c |   21 ++++++++++++++++-----
>  1 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
> index f843a88..43893ba 100644
> --- a/net/netfilter/ipvs/ip_vs_proto.c
> +++ b/net/netfilter/ipvs/ip_vs_proto.c
> @@ -316,20 +316,31 @@ ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
>   */
>  int __net_init ip_vs_protocol_net_init(struct net *net)
>  {
> +	int ret;
>  #ifdef CONFIG_IP_VS_PROTO_TCP
> -	register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> +	if (ret < 0)
> +		return ret;
>  #endif
>  #ifdef CONFIG_IP_VS_PROTO_UDP
> -	register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> +	if (ret < 0)
> +		return ret;

If you return here, I think you'll leave things in inconsistent state,
ie. the tcp protocol is registered. You have to unregister it before
leaving.

ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
if (ret < 0)
        goto err_tcp;

...
err_tcp:
        unregister_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - April 11, 2012, 11:46 p.m.
On Thu, Apr 12, 2012 at 01:22:43AM +0200, Pablo Neira Ayuso wrote:
> On Thu, Apr 05, 2012 at 07:24:33PM -0400, Sasha Levin wrote:
> > The registration of a protocol might fail, there were no checks
> > and all registrations were assumed to be correct. This lead to
> > NULL ptr dereferences when apps tried registering.
> > 
> > For example:
> > 
> > [ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> > [ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> > [ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
> > [ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
> > [ 1293.227038] CPU 1
> > [ 1293.227038] Pid: 19609, comm: trinity Tainted: G        W    3.4.0-rc1-next-20120405-sasha-dirty #57
> > [ 1293.227038] RIP: 0010:[<ffffffff822aacb0>]  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> > [ 1293.227038] RSP: 0018:ffff880038c1dd18  EFLAGS: 00010286
> > [ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
> > [ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
> > [ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
> > [ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
> > [ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
> > [ 1293.227038] FS:  00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
> > [ 1293.227038] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
> > [ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
> > [ 1293.227038] Stack:
> > [ 1293.227038]  ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
> > [ 1293.227038]  ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
> > [ 1293.227038]  0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
> > [ 1293.227038] Call Trace:
> > [ 1293.227038]  [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
> > [ 1293.227038]  [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
> > [ 1293.227038]  [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
> > [ 1293.227038]  [<ffffffff821c9060>] ops_init+0x80/0x90
> > [ 1293.227038]  [<ffffffff821c90cb>] setup_net+0x5b/0xe0
> > [ 1293.227038]  [<ffffffff821c9416>] copy_net_ns+0x76/0x100
> > [ 1293.227038]  [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
> > [ 1293.227038]  [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
> > [ 1293.227038]  [<ffffffff810afd1f>] sys_unshare+0xff/0x290
> > [ 1293.227038]  [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > [ 1293.227038]  [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
> > [ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
> > [ 1293.227038] RIP  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> > [ 1293.227038]  RSP <ffff880038c1dd18>
> > [ 1293.227038] CR2: 0000000000000018
> > [ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
> > [ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
> > 
> > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> > ---
> >  net/netfilter/ipvs/ip_vs_proto.c |   21 ++++++++++++++++-----
> >  1 files changed, 16 insertions(+), 5 deletions(-)
> > 
> > diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
> > index f843a88..43893ba 100644
> > --- a/net/netfilter/ipvs/ip_vs_proto.c
> > +++ b/net/netfilter/ipvs/ip_vs_proto.c
> > @@ -316,20 +316,31 @@ ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
> >   */
> >  int __net_init ip_vs_protocol_net_init(struct net *net)
> >  {
> > +	int ret;
> >  #ifdef CONFIG_IP_VS_PROTO_TCP
> > -	register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> > +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> > +	if (ret < 0)
> > +		return ret;
> >  #endif
> >  #ifdef CONFIG_IP_VS_PROTO_UDP
> > -	register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> > +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> > +	if (ret < 0)
> > +		return ret;
> 
> If you return here, I think you'll leave things in inconsistent state,
> ie. the tcp protocol is registered. You have to unregister it before
> leaving.
> 
> ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
                                                        ^^^
sorry, I meant to say udp here.

> if (ret < 0)
>         goto err_tcp;
                   ^^^
and here.

> ...
> err_tcp:
>         unregister_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman - April 12, 2012, 9:41 p.m.
On Thu, Apr 12, 2012 at 01:46:28AM +0200, Pablo Neira Ayuso wrote:
> On Thu, Apr 12, 2012 at 01:22:43AM +0200, Pablo Neira Ayuso wrote:
> > On Thu, Apr 05, 2012 at 07:24:33PM -0400, Sasha Levin wrote:
> > > The registration of a protocol might fail, there were no checks
> > > and all registrations were assumed to be correct. This lead to
> > > NULL ptr dereferences when apps tried registering.
> > > 
> > > For example:
> > > 
> > > [ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> > > [ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> > > [ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
> > > [ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
> > > [ 1293.227038] CPU 1
> > > [ 1293.227038] Pid: 19609, comm: trinity Tainted: G        W    3.4.0-rc1-next-20120405-sasha-dirty #57
> > > [ 1293.227038] RIP: 0010:[<ffffffff822aacb0>]  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> > > [ 1293.227038] RSP: 0018:ffff880038c1dd18  EFLAGS: 00010286
> > > [ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
> > > [ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
> > > [ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
> > > [ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
> > > [ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
> > > [ 1293.227038] FS:  00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
> > > [ 1293.227038] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > [ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
> > > [ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > [ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > [ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
> > > [ 1293.227038] Stack:
> > > [ 1293.227038]  ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
> > > [ 1293.227038]  ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
> > > [ 1293.227038]  0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
> > > [ 1293.227038] Call Trace:
> > > [ 1293.227038]  [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
> > > [ 1293.227038]  [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
> > > [ 1293.227038]  [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
> > > [ 1293.227038]  [<ffffffff821c9060>] ops_init+0x80/0x90
> > > [ 1293.227038]  [<ffffffff821c90cb>] setup_net+0x5b/0xe0
> > > [ 1293.227038]  [<ffffffff821c9416>] copy_net_ns+0x76/0x100
> > > [ 1293.227038]  [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
> > > [ 1293.227038]  [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
> > > [ 1293.227038]  [<ffffffff810afd1f>] sys_unshare+0xff/0x290
> > > [ 1293.227038]  [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > > [ 1293.227038]  [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
> > > [ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
> > > [ 1293.227038] RIP  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> > > [ 1293.227038]  RSP <ffff880038c1dd18>
> > > [ 1293.227038] CR2: 0000000000000018
> > > [ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
> > > [ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
> > > 
> > > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> > > ---
> > >  net/netfilter/ipvs/ip_vs_proto.c |   21 ++++++++++++++++-----
> > >  1 files changed, 16 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
> > > index f843a88..43893ba 100644
> > > --- a/net/netfilter/ipvs/ip_vs_proto.c
> > > +++ b/net/netfilter/ipvs/ip_vs_proto.c
> > > @@ -316,20 +316,31 @@ ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
> > >   */
> > >  int __net_init ip_vs_protocol_net_init(struct net *net)
> > >  {
> > > +	int ret;
> > >  #ifdef CONFIG_IP_VS_PROTO_TCP
> > > -	register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> > > +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> > > +	if (ret < 0)
> > > +		return ret;
> > >  #endif
> > >  #ifdef CONFIG_IP_VS_PROTO_UDP
> > > -	register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> > > +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> > > +	if (ret < 0)
> > > +		return ret;
> > 
> > If you return here, I think you'll leave things in inconsistent state,
> > ie. the tcp protocol is registered. You have to unregister it before
> > leaving.
> > 
> > ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
>                                                         ^^^
> sorry, I meant to say udp here.
> 
> > if (ret < 0)
> >         goto err_tcp;
>                    ^^^
> and here.
> 
> > ...
> > err_tcp:
> >         unregister_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> 

Thanks Pablo,

I was thinking along those lines too.
I'll send an updated patch.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sasha Levin - April 13, 2012, 12:54 a.m.
On Thu, Apr 12, 2012 at 1:46 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>> If you return here, I think you'll leave things in inconsistent state,
>> ie. the tcp protocol is registered. You have to unregister it before
>> leaving.

I thought that the cleanup callback is getting called for failed init
calls, if that's not the case then we can probably call it ourselves
if any of these failed.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman - April 13, 2012, 4:11 a.m.
On Fri, Apr 13, 2012 at 02:54:13AM +0200, Sasha Levin wrote:
> On Thu, Apr 12, 2012 at 1:46 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> >> If you return here, I think you'll leave things in inconsistent state,
> >> ie. the tcp protocol is registered. You have to unregister it before
> >> leaving.
> 
> I thought that the cleanup callback is getting called for failed init
> calls, if that's not the case then we can probably call it ourselves
> if any of these failed.

Good point. In any case, I think that I have found a new problem.

With your proposed patch in place I see a panic in ftp helper registration
in the case where protocol registration fails. I have not had any
luck resolving this so far. Perhaps ipvs->net needs to be reset to NULL
if initialisation fails and that can be checked when modules register
themselves?

IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
IPVS: Each connection entry needs 264 bytes at least
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1
IPVS: [rr] scheduler registered.
IPVS: [wrr] scheduler registered.
IPVS: [lc] scheduler registered.
IPVS: [wlc] scheduler registered.
IPVS: [lblc] scheduler registered.
IPVS: [lblcr] scheduler registered.
IPVS: [dh] scheduler registered.
IPVS: [sh] scheduler registered.
IPVS: [sed] scheduler registered.
IPVS: [nq] scheduler registered.
general protection fault: 0000 [#1] SMP
CPU 0
Modules linked in:

Pid: 1, comm: swapper/0 Not tainted 3.3.0-03812-gf51f739 #219 Bochs Bochs
RIP: 0010:[<ffffffff811e21ba>]  [<ffffffff811e21ba>] register_ip_vs_app+0x3a/0x70
RSP: 0018:ffff880002039df0  EFLAGS: 00010246
RAX: 002a002900280027 RBX: ffff8800020ce680 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8800020ce680 RDI: ffffffff8162ab80
RBP: ffff880002039e00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff880003916800
R13: 00000000fffffff4 R14: ffffffff816e5f00 R15: ffff880003916800
FS:  0000000000000000(0000) GS:ffff880002600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000004697e0 CR3: 0000000001605000 CR4: 00000000000006b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/0 (pid: 1, threadinfo ffff880002038000, task ffff8800020375a0)
Stack:
 ffff8800020ce680 0000000000000000 ffff880002039e50 ffffffff81675610
 ffffffff81614060 00ffffff00000006 ffffffff8149dc9d ffffffff8162b8a0
 0000000000000000 ffffffff81675699 0000000000000000 0000000000000000
Call Trace:
 [<ffffffff81675610>] __ip_vs_ftp_init+0x6b/0xf4
 [<ffffffff81675699>] ? __ip_vs_ftp_init+0xf4/0xf4
 [<ffffffff811a6011>] ops_init.constprop.11+0x91/0x110
 [<ffffffff81675699>] ? __ip_vs_ftp_init+0xf4/0xf4
 [<ffffffff811a60fc>] register_pernet_operations.isra.8+0x6c/0xc0
 [<ffffffff811a61e0>] register_pernet_subsys+0x20/0x40
 [<ffffffff81675593>] ? ip_vs_sed_init+0x12/0x12
 [<ffffffff816756a9>] ip_vs_ftp_init+0x10/0x12
 [<ffffffff810001ca>] do_one_initcall+0x3a/0x160
 [<ffffffff81654bae>] kernel_init+0x9b/0x115
 [<ffffffff81298bf4>] kernel_thread_helper+0x4/0x10
 [<ffffffff81654b13>] ? start_kernel+0x31d/0x31d
 [<ffffffff81298bf0>] ? gs_change+0xb/0xb
Code: f8 48 89 f3 4c 8b a7 40 09 00 00 e8 e1 a6 ff ff 48 c7 c7 80 ab 62 81 e8 25 30 0b 00 49 8b 84 24 08 01 00 00 48 c7 c7 80 ab 62 81 <48> 89 58 08 48 89 03 49 8d 84 24 08 01 00 00 48 89 43 08 49 89
RIP  [<ffffffff811e21ba>] register_ip_vs_app+0x3a/0x70
 RSP <ffff880002039df0>
---[ end trace 3e5d9bede957f8b4 ]---

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman - April 13, 2012, 6:22 a.m.
On Fri, Apr 13, 2012 at 01:11:50PM +0900, Simon Horman wrote:
> On Fri, Apr 13, 2012 at 02:54:13AM +0200, Sasha Levin wrote:
> > On Thu, Apr 12, 2012 at 1:46 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > >> If you return here, I think you'll leave things in inconsistent state,
> > >> ie. the tcp protocol is registered. You have to unregister it before
> > >> leaving.
> > 
> > I thought that the cleanup callback is getting called for failed init
> > calls, if that's not the case then we can probably call it ourselves
> > if any of these failed.
> 
> Good point. In any case, I think that I have found a new problem.

[sni@]

I have confirmed that the cleanup code is called on error, so I think that
your existing patch is fine.

Acked-by: Simon Horman <horms@verge.net.au>

Pablo, please consider taking this change. The other problem I raised,
though related, can be handled separately as it won't occur if the
ftp helper isn't initialised.

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hans Schillstrom - April 13, 2012, 8:03 a.m.
Hello Simon and Sasha
Sorry for not helping been quite busy for a while

On Friday 13 April 2012 06:11:50 Simon Horman wrote:
> On Fri, Apr 13, 2012 at 02:54:13AM +0200, Sasha Levin wrote:
> > On Thu, Apr 12, 2012 at 1:46 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > >> If you return here, I think you'll leave things in inconsistent state,
> > >> ie. the tcp protocol is registered. You have to unregister it before
> > >> leaving.
> > 
> > I thought that the cleanup callback is getting called for failed init
> > calls, if that's not the case then we can probably call it ourselves
> > if any of these failed.
> 
> Good point. In any case, I think that I have found a new problem.
> 
> With your proposed patch in place I see a panic in ftp helper registration
> in the case where protocol registration fails. I have not had any
> luck resolving this so far. Perhaps ipvs->net needs to be reset to NULL
> if initialisation fails and that can be checked when modules register
> themselves?
I think Pablo was touching the root cause,

There is a generic fault in the patch, you must take care of un_register of the protocol
i.e. my sugguestion is do like this:

#ifdef CONFIG_IP_VS_PROTO_TCP
	if (register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp) < 0)
		goto unreg;
#endif
#ifdef CONFIG_IP_VS_PROTO_UDP
	if (register_ip_vs_proto_netns(net, &ip_vs_protocol_udp) < 0)
		goto unreg;
#endif
...

unreg:
	ip_vs_protocol_net_cleanup(net);
	return -ENOMEM;
}

and in register_ip_vs_proto_netns() kzalloc() could be changed to GFP_KERNEL 
since this will allways be called from process context


> 
> IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
> IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
> IPVS: Each connection entry needs 264 bytes at least
> input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1
> IPVS: [rr] scheduler registered.
> IPVS: [wrr] scheduler registered.
> IPVS: [lc] scheduler registered.
> IPVS: [wlc] scheduler registered.
> IPVS: [lblc] scheduler registered.
> IPVS: [lblcr] scheduler registered.
> IPVS: [dh] scheduler registered.
> IPVS: [sh] scheduler registered.
> IPVS: [sed] scheduler registered.
> IPVS: [nq] scheduler registered.
> general protection fault: 0000 [#1] SMP
> CPU 0
> Modules linked in:
> 
> Pid: 1, comm: swapper/0 Not tainted 3.3.0-03812-gf51f739 #219 Bochs Bochs
> RIP: 0010:[<ffffffff811e21ba>]  [<ffffffff811e21ba>] register_ip_vs_app+0x3a/0x70
> RSP: 0018:ffff880002039df0  EFLAGS: 00010246
> RAX: 002a002900280027 RBX: ffff8800020ce680 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffff8800020ce680 RDI: ffffffff8162ab80
> RBP: ffff880002039e00 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000001 R12: ffff880003916800
> R13: 00000000fffffff4 R14: ffffffff816e5f00 R15: ffff880003916800
> FS:  0000000000000000(0000) GS:ffff880002600000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000004697e0 CR3: 0000000001605000 CR4: 00000000000006b0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper/0 (pid: 1, threadinfo ffff880002038000, task ffff8800020375a0)
> Stack:
>  ffff8800020ce680 0000000000000000 ffff880002039e50 ffffffff81675610
>  ffffffff81614060 00ffffff00000006 ffffffff8149dc9d ffffffff8162b8a0
>  0000000000000000 ffffffff81675699 0000000000000000 0000000000000000
> Call Trace:
>  [<ffffffff81675610>] __ip_vs_ftp_init+0x6b/0xf4
>  [<ffffffff81675699>] ? __ip_vs_ftp_init+0xf4/0xf4
>  [<ffffffff811a6011>] ops_init.constprop.11+0x91/0x110
>  [<ffffffff81675699>] ? __ip_vs_ftp_init+0xf4/0xf4
>  [<ffffffff811a60fc>] register_pernet_operations.isra.8+0x6c/0xc0
>  [<ffffffff811a61e0>] register_pernet_subsys+0x20/0x40
>  [<ffffffff81675593>] ? ip_vs_sed_init+0x12/0x12
>  [<ffffffff816756a9>] ip_vs_ftp_init+0x10/0x12
>  [<ffffffff810001ca>] do_one_initcall+0x3a/0x160
>  [<ffffffff81654bae>] kernel_init+0x9b/0x115
>  [<ffffffff81298bf4>] kernel_thread_helper+0x4/0x10
>  [<ffffffff81654b13>] ? start_kernel+0x31d/0x31d
>  [<ffffffff81298bf0>] ? gs_change+0xb/0xb
> Code: f8 48 89 f3 4c 8b a7 40 09 00 00 e8 e1 a6 ff ff 48 c7 c7 80 ab 62 81 e8 25 30 0b 00 49 8b 84 24 08 01 00 00 48 c7 c7 80 ab 62 81 <48> 89 58 08 48 89 03 49 8d 84 24 08 01 00 00 48 89 43 08 49 89
> RIP  [<ffffffff811e21ba>] register_ip_vs_app+0x3a/0x70
>  RSP <ffff880002039df0>
> ---[ end trace 3e5d9bede957f8b4 ]---
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Julian Anastasov - April 13, 2012, 8:35 a.m.
Hello,

On Fri, 13 Apr 2012, Simon Horman wrote:

> On Fri, Apr 13, 2012 at 01:11:50PM +0900, Simon Horman wrote:
> > On Fri, Apr 13, 2012 at 02:54:13AM +0200, Sasha Levin wrote:
> > > On Thu, Apr 12, 2012 at 1:46 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > >> If you return here, I think you'll leave things in inconsistent state,
> > > >> ie. the tcp protocol is registered. You have to unregister it before
> > > >> leaving.
> > > 
> > > I thought that the cleanup callback is getting called for failed init
> > > calls, if that's not the case then we can probably call it ourselves
> > > if any of these failed.
> > 
> > Good point. In any case, I think that I have found a new problem.
> 
> [sni@]
> 
> I have confirmed that the cleanup code is called on error, so I think that
> your existing patch is fine.
> 
> Acked-by: Simon Horman <horms@verge.net.au>
> 
> Pablo, please consider taking this change. The other problem I raised,
> though related, can be handled separately as it won't occur if the
> ftp helper isn't initialised.

	Simon, I'm sending 2 patches for this ftp problem
in separate thread. Please, test if the problem is solved.

Regards

--
Julian Anastasov <ja@ssi.bg>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Julian Anastasov - April 13, 2012, 9:13 p.m.
Hello,

On Thu, 5 Apr 2012, Sasha Levin wrote:

> The registration of a protocol might fail, there were no checks
> and all registrations were assumed to be correct. This lead to
> NULL ptr dereferences when apps tried registering.
> 
> For example:
> 
> [ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> [ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
> [ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
> [ 1293.227038] CPU 1
> [ 1293.227038] Pid: 19609, comm: trinity Tainted: G        W    3.4.0-rc1-next-20120405-sasha-dirty #57
> [ 1293.227038] RIP: 0010:[<ffffffff822aacb0>]  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038] RSP: 0018:ffff880038c1dd18  EFLAGS: 00010286
> [ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
> [ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
> [ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
> [ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
> [ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
> [ 1293.227038] FS:  00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
> [ 1293.227038] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
> [ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
> [ 1293.227038] Stack:
> [ 1293.227038]  ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
> [ 1293.227038]  ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
> [ 1293.227038]  0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
> [ 1293.227038] Call Trace:
> [ 1293.227038]  [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
> [ 1293.227038]  [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
> [ 1293.227038]  [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
> [ 1293.227038]  [<ffffffff821c9060>] ops_init+0x80/0x90
> [ 1293.227038]  [<ffffffff821c90cb>] setup_net+0x5b/0xe0
> [ 1293.227038]  [<ffffffff821c9416>] copy_net_ns+0x76/0x100
> [ 1293.227038]  [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
> [ 1293.227038]  [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
> [ 1293.227038]  [<ffffffff810afd1f>] sys_unshare+0xff/0x290
> [ 1293.227038]  [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 1293.227038]  [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
> [ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
> [ 1293.227038] RIP  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038]  RSP <ffff880038c1dd18>
> [ 1293.227038] CR2: 0000000000000018
> [ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
> [ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
> 
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> ---
>  net/netfilter/ipvs/ip_vs_proto.c |   21 ++++++++++++++++-----
>  1 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
> index f843a88..43893ba 100644
> --- a/net/netfilter/ipvs/ip_vs_proto.c
> +++ b/net/netfilter/ipvs/ip_vs_proto.c
> @@ -316,20 +316,31 @@ ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
>   */
>  int __net_init ip_vs_protocol_net_init(struct net *net)
>  {
> +	int ret;
>  #ifdef CONFIG_IP_VS_PROTO_TCP
> -	register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> +	if (ret < 0)
> +		return ret;

	Use goto cleanup instead of return ret;

>  #endif
>  #ifdef CONFIG_IP_VS_PROTO_UDP
> -	register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> +	if (ret < 0)
> +		return ret;
>  #endif
>  #ifdef CONFIG_IP_VS_PROTO_SCTP
> -	register_ip_vs_proto_netns(net, &ip_vs_protocol_sctp);
> +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_sctp);
> +	if (ret < 0)
> +		return ret;
>  #endif
>  #ifdef CONFIG_IP_VS_PROTO_AH
> -	register_ip_vs_proto_netns(net, &ip_vs_protocol_ah);
> +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_ah);
> +	if (ret < 0)
> +		return ret;
>  #endif
>  #ifdef CONFIG_IP_VS_PROTO_ESP
> -	register_ip_vs_proto_netns(net, &ip_vs_protocol_esp);
> +	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_esp);
> +	if (ret < 0)
> +		return ret;
>  #endif
>  	return 0;

	You have to call ip_vs_protocol_net_cleanup(net) here
because if ip_vs_protocol_net_init fails it is not called.
Your change is not enough.

	To avoid compiler warnings when no protocol is
configured, may be it is better to add all protos in array:

static struct ip_vs_protocol *protos[] = {
#ifdef CONFIG_IP_VS_PROTO_TCP
	&ip_vs_protocol_tcp,
#endif
	...
};

	Then we can loop where needed:

	for (i = 0; i < ARRAY_SIZE(protos); i++) {
		ret = register_ip_vs_proto_netns(net, protos[i]);
		if (ret < 0)
			goto cleanup;
	}
	return 0;

cleanup:
	ip_vs_protocol_net_cleanup(net);
	return ret;

	I rely on you also to change the GFP_ATOMIC in
register_ip_vs_proto_netns. Let me know if you plan
to make these changes or prefer someone else to take care.

Regards

--
Julian Anastasov <ja@ssi.bg>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
index f843a88..43893ba 100644
--- a/net/netfilter/ipvs/ip_vs_proto.c
+++ b/net/netfilter/ipvs/ip_vs_proto.c
@@ -316,20 +316,31 @@  ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
  */
 int __net_init ip_vs_protocol_net_init(struct net *net)
 {
+	int ret;
 #ifdef CONFIG_IP_VS_PROTO_TCP
-	register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
+	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
+	if (ret < 0)
+		return ret;
 #endif
 #ifdef CONFIG_IP_VS_PROTO_UDP
-	register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
+	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
+	if (ret < 0)
+		return ret;
 #endif
 #ifdef CONFIG_IP_VS_PROTO_SCTP
-	register_ip_vs_proto_netns(net, &ip_vs_protocol_sctp);
+	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_sctp);
+	if (ret < 0)
+		return ret;
 #endif
 #ifdef CONFIG_IP_VS_PROTO_AH
-	register_ip_vs_proto_netns(net, &ip_vs_protocol_ah);
+	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_ah);
+	if (ret < 0)
+		return ret;
 #endif
 #ifdef CONFIG_IP_VS_PROTO_ESP
-	register_ip_vs_proto_netns(net, &ip_vs_protocol_esp);
+	ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_esp);
+	if (ret < 0)
+		return ret;
 #endif
 	return 0;
 }