Patchwork af_key: return error if pfkey_xfrm_policy2msg_prep() fails

login
register
mail settings
Submitter Dan Carpenter
Date March 24, 2010, 11:47 a.m.
Message ID <20100324114700.GB21571@bicker>
Download mbox | patch
Permalink /patch/48397/
State Accepted
Delegated to: David Miller
Headers show

Comments

Dan Carpenter - March 24, 2010, 11:47 a.m.
The original code saved the error value but just returned 0 in the end.

Signed-off-by: Dan Carpenter <error27@gmail.com>

--
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
jamal - March 24, 2010, 1:46 p.m.
On Wed, 2010-03-24 at 14:47 +0300, Dan Carpenter wrote:
> The original code saved the error value but just returned 0 in the end.

Looks reasonable and harmless. 
If you have time - can you try this one test with your patch and see if
any strange message shows up when you delete? add a policy on window1,
on window2 run ip xfrm mon and then back on window1 delete it and watch
the event on window2

----
window2: ip xfrm mon

window1, add:
ip xfrm policy add src 172.16.2.0/24 dst 172.16.1.0/24 \
        dir fwd ptype main \
        tmpl src 192.168.2.100 dst 192.168.1.100 \
        proto esp mode tunnel


window1, delete:
ip xfrm pol del src 172.16.2.0/24 dst 172.16.1.0/24 dir fwd
----

cheers,
jamal

--
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
Dan Carpenter - March 24, 2010, 4:19 p.m.
On Wed, Mar 24, 2010 at 09:46:23AM -0400, jamal wrote:
> On Wed, 2010-03-24 at 14:47 +0300, Dan Carpenter wrote:
> > The original code saved the error value but just returned 0 in the end.
> 
> Looks reasonable and harmless. 
> If you have time - can you try this one test with your patch and see if
> any strange message shows up when you delete? add a policy on window1,
> on window2 run ip xfrm mon and then back on window1 delete it and watch
> the event on window2
> 
> ----
> window2: ip xfrm mon
> 
> window1, add:
> ip xfrm policy add src 172.16.2.0/24 dst 172.16.1.0/24 \
>         dir fwd ptype main \
>         tmpl src 192.168.2.100 dst 192.168.1.100 \
>         proto esp mode tunnel
> 
> 
> window1, delete:
> ip xfrm pol del src 172.16.2.0/24 dst 172.16.1.0/24 dir fwd
> ----

Sure.  I tried that and it looks OK.  

The truth is that I don't understand this code very well.  I'm just writing
patches based on static analysis.  Here is the output from window1:

$ sudo ip xfrm mon
src 172.16.2.0/24 dst 172.16.1.0/24 
	dir fwd priority 0 
	tmpl src 192.168.2.100 dst 192.168.1.100
		proto esp reqid 0 mode tunnel
Deleted src 172.16.2.0/24 dst 172.16.1.0/24 
	dir fwd priority 0 
	tmpl src 192.168.2.100 dst 192.168.1.100
		proto esp reqid 0 mode tunnel

There aren't any messages in dmesg either.

regards,
dan carpenter
--
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
jamal - March 24, 2010, 4:39 p.m.
On Wed, 2010-03-24 at 19:19 +0300, Dan Carpenter wrote:
> On Wed, Mar 24, 2010 at 09:46:23AM -0400, jamal wrote:
> > On Wed, 2010-03-24 at 14:47 +0300, Dan Carpenter wrote:
> > > The original code saved the error value but just returned 0 in the end.
> > 
> > Looks reasonable and harmless. 
> > If you have time - can you try this one test with your patch and see if
> > any strange message shows up when you delete? add a policy on window1,
> > on window2 run ip xfrm mon and then back on window1 delete it and watch
> > the event on window2
> > 
> > ----
> > window2: ip xfrm mon
> > 
> > window1, add:
> > ip xfrm policy add src 172.16.2.0/24 dst 172.16.1.0/24 \
> >         dir fwd ptype main \
> >         tmpl src 192.168.2.100 dst 192.168.1.100 \
> >         proto esp mode tunnel
> > 
> > 
> > window1, delete:
> > ip xfrm pol del src 172.16.2.0/24 dst 172.16.1.0/24 dir fwd
> > ----
> 
> Sure.  I tried that and it looks OK.  
> 

I am really sorry - your patch is pfkey path and the example i gave you
is xfrm based;-< I worry too much, so never mind - the change seems
harmless enough:
Acked-by: Jamal Hadi Salim <hadi@mojatatu.com>


cheers,
jamal

--
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
David Miller - March 24, 2010, 8:28 p.m.
From: jamal <hadi@cyberus.ca>
Date: Wed, 24 Mar 2010 12:39:50 -0400

> I am really sorry - your patch is pfkey path and the example i gave you
> is xfrm based;-< I worry too much, so never mind - the change seems
> harmless enough:
> Acked-by: Jamal Hadi Salim <hadi@mojatatu.com>

Applied, thanks everyone.
--
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

Patch

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 3687078..344145f 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2129,10 +2129,9 @@  static int key_notify_policy(struct xfrm_policy *xp, int dir, struct km_event *c
 	int err;
 
 	out_skb = pfkey_xfrm_policy2msg_prep(xp);
-	if (IS_ERR(out_skb)) {
-		err = PTR_ERR(out_skb);
-		goto out;
-	}
+	if (IS_ERR(out_skb))
+		return PTR_ERR(out_skb);
+
 	err = pfkey_xfrm_policy2msg(out_skb, xp, dir);
 	if (err < 0)
 		return err;
@@ -2148,7 +2147,6 @@  static int key_notify_policy(struct xfrm_policy *xp, int dir, struct km_event *c
 	out_hdr->sadb_msg_seq = c->seq;
 	out_hdr->sadb_msg_pid = c->pid;
 	pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, NULL, xp_net(xp));
-out:
 	return 0;
 
 }