netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns.
@ 2008-03-06 11:18 Pavel Emelyanov
  2008-03-11 13:24 ` Pavel Emelyanov
  2008-03-24  4:49 ` [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns David Miller
  0 siblings, 2 replies; 10+ messages in thread
From: Pavel Emelyanov @ 2008-03-06 11:18 UTC (permalink / raw)
  To: David Miller; +Cc: Linux Netdev List

Proxy neighbors do not have any reference counting, so any caller
of pneigh_lookup (unless it's a netlink triggered add/del routine)
should _not_ perform any actions on the found proxy entry. 

There's one exception from this rule - the ipv6's ndisc_recv_ns() 
uses found entry to check the flags for NTF_ROUTER.

This creates a race between the ndisc and pneigh_delete - after 
the pneigh is returned to the caller, the nd_tbl.lock is dropped 
and the deleting procedure may proceed.

One of the fixes would be to add a reference counting, but this
problem exists for ndisc only. Besides such a patch would be too 
big for -rc4.

So I propose to introduce a __pneigh_lookup() which is supposed
to be called with the lock held and use it in ndisc code to check
the flags on alive pneigh entry. 

If this is OK, is there a real need in proxy neighbors reference
counting for 2.6.26 :) ?

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>

---

diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index ebbfb50..cca1904 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -218,6 +218,8 @@ extern unsigned long		neigh_rand_reach_time(unsigned long base);
 extern void			pneigh_enqueue(struct neigh_table *tbl, struct neigh_parms *p,
 					       struct sk_buff *skb);
 extern struct pneigh_entry	*pneigh_lookup(struct neigh_table *tbl, struct net *net, const void *key, struct net_device *dev, int creat);
+extern struct pneigh_entry	*__pneigh_lookup(struct neigh_table *tbl,
+		struct net *net, const void *key, struct net_device *dev);
 extern int			pneigh_delete(struct neigh_table *tbl, struct net *net, const void *key, struct net_device *dev);
 
 extern void neigh_app_ns(struct neighbour *n);
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index d9a02b2..c97bf5b 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -466,6 +466,28 @@ out_neigh_release:
 	goto out;
 }
 
+struct pneigh_entry *__pneigh_lookup(struct neigh_table *tbl,
+		struct net *net, const void *pkey, struct net_device *dev)
+{
+	struct pneigh_entry *n;
+	int key_len = tbl->key_len;
+	u32 hash_val = *(u32 *)(pkey + key_len - 4);
+
+	hash_val ^= (hash_val >> 16);
+	hash_val ^= hash_val >> 8;
+	hash_val ^= hash_val >> 4;
+	hash_val &= PNEIGH_HASHMASK;
+
+	for (n = tbl->phash_buckets[hash_val]; n; n = n->next) {
+		if (!memcmp(n->key, pkey, key_len) &&
+		    (n->net == net) &&
+		    (n->dev == dev || !n->dev))
+			break;
+	}
+
+	return n;
+}
+
 struct pneigh_entry * pneigh_lookup(struct neigh_table *tbl,
 				    struct net *net, const void *pkey,
 				    struct net_device *dev, int creat)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 0d33a7d..bb72ef4 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -676,6 +676,20 @@ static void ndisc_solicit(struct neighbour *neigh, struct sk_buff *skb)
 	}
 }
 
+static struct pneigh_entry *neigh_check_router(struct net_device *dev,
+		struct in6_addr *addr, int *is_router)
+{
+	struct pneigh_entry *n;
+
+	read_lock_bh(&nd_tbl.lock);
+	n = __pneigh_lookup(&nd_tbl, &init_net, addr, dev);
+	if (n != NULL)
+		*is_router = (n->flags & NTF_ROUTER);
+	read_unlock_bh(&nd_tbl.lock);
+
+	return n;
+}
+
 static void ndisc_recv_ns(struct sk_buff *skb)
 {
 	struct nd_msg *msg = (struct nd_msg *)skb_transport_header(skb);
@@ -790,8 +804,8 @@ static void ndisc_recv_ns(struct sk_buff *skb)
 		if (ipv6_chk_acast_addr(dev, &msg->target) ||
 		    (idev->cnf.forwarding &&
 		     (ipv6_devconf.proxy_ndp || idev->cnf.proxy_ndp) &&
-		     (pneigh = pneigh_lookup(&nd_tbl, &init_net,
-					     &msg->target, dev, 0)) != NULL)) {
+		     (pneigh = neigh_check_router(dev, &msg->target,
+						  &is_router)) != NULL)) {
 			if (!(NEIGH_CB(skb)->flags & LOCALLY_ENQUEUED) &&
 			    skb->pkt_type != PACKET_HOST &&
 			    inc != 0 &&
@@ -812,7 +826,7 @@ static void ndisc_recv_ns(struct sk_buff *skb)
 			goto out;
 	}
 
-	is_router = !!(pneigh ? pneigh->flags & NTF_ROUTER : idev->cnf.forwarding);
+	is_router = !!(pneigh ? is_router : idev->cnf.forwarding);
 
 	if (dad) {
 		struct in6_addr maddr;

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns.
  2008-03-06 11:18 [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns Pavel Emelyanov
@ 2008-03-11 13:24 ` Pavel Emelyanov
  2008-03-12  0:52   ` David Miller
  2008-03-24  4:49 ` [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns David Miller
  1 sibling, 1 reply; 10+ messages in thread
From: Pavel Emelyanov @ 2008-03-11 13:24 UTC (permalink / raw)
  To: David Miller; +Cc: Linux Netdev List

Hi, David.

You picked up the patch with /proc/net symlink, but skipped this
one, while it was sent earlier. Is it _that_ bad :) ?

Thanks,
Pavel

> Proxy neighbors do not have any reference counting, so any caller
> of pneigh_lookup (unless it's a netlink triggered add/del routine)
> should _not_ perform any actions on the found proxy entry. 
> 
> There's one exception from this rule - the ipv6's ndisc_recv_ns() 
> uses found entry to check the flags for NTF_ROUTER.
> 
> This creates a race between the ndisc and pneigh_delete - after 
> the pneigh is returned to the caller, the nd_tbl.lock is dropped 
> and the deleting procedure may proceed.
> 
> One of the fixes would be to add a reference counting, but this
> problem exists for ndisc only. Besides such a patch would be too 
> big for -rc4.
> 
> So I propose to introduce a __pneigh_lookup() which is supposed
> to be called with the lock held and use it in ndisc code to check
> the flags on alive pneigh entry. 
> 
> If this is OK, is there a real need in proxy neighbors reference
> counting for 2.6.26 :) ?
> 
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> 
> ---
> 
> diff --git a/include/net/neighbour.h b/include/net/neighbour.h
> index ebbfb50..cca1904 100644
> --- a/include/net/neighbour.h
> +++ b/include/net/neighbour.h
> @@ -218,6 +218,8 @@ extern unsigned long		neigh_rand_reach_time(unsigned long base);
>  extern void			pneigh_enqueue(struct neigh_table *tbl, struct neigh_parms *p,
>  					       struct sk_buff *skb);
>  extern struct pneigh_entry	*pneigh_lookup(struct neigh_table *tbl, struct net *net, const void *key, struct net_device *dev, int creat);
> +extern struct pneigh_entry	*__pneigh_lookup(struct neigh_table *tbl,
> +		struct net *net, const void *key, struct net_device *dev);
>  extern int			pneigh_delete(struct neigh_table *tbl, struct net *net, const void *key, struct net_device *dev);
>  
>  extern void neigh_app_ns(struct neighbour *n);
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index d9a02b2..c97bf5b 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -466,6 +466,28 @@ out_neigh_release:
>  	goto out;
>  }
>  
> +struct pneigh_entry *__pneigh_lookup(struct neigh_table *tbl,
> +		struct net *net, const void *pkey, struct net_device *dev)
> +{
> +	struct pneigh_entry *n;
> +	int key_len = tbl->key_len;
> +	u32 hash_val = *(u32 *)(pkey + key_len - 4);
> +
> +	hash_val ^= (hash_val >> 16);
> +	hash_val ^= hash_val >> 8;
> +	hash_val ^= hash_val >> 4;
> +	hash_val &= PNEIGH_HASHMASK;
> +
> +	for (n = tbl->phash_buckets[hash_val]; n; n = n->next) {
> +		if (!memcmp(n->key, pkey, key_len) &&
> +		    (n->net == net) &&
> +		    (n->dev == dev || !n->dev))
> +			break;
> +	}
> +
> +	return n;
> +}
> +
>  struct pneigh_entry * pneigh_lookup(struct neigh_table *tbl,
>  				    struct net *net, const void *pkey,
>  				    struct net_device *dev, int creat)
> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> index 0d33a7d..bb72ef4 100644
> --- a/net/ipv6/ndisc.c
> +++ b/net/ipv6/ndisc.c
> @@ -676,6 +676,20 @@ static void ndisc_solicit(struct neighbour *neigh, struct sk_buff *skb)
>  	}
>  }
>  
> +static struct pneigh_entry *neigh_check_router(struct net_device *dev,
> +		struct in6_addr *addr, int *is_router)
> +{
> +	struct pneigh_entry *n;
> +
> +	read_lock_bh(&nd_tbl.lock);
> +	n = __pneigh_lookup(&nd_tbl, &init_net, addr, dev);
> +	if (n != NULL)
> +		*is_router = (n->flags & NTF_ROUTER);
> +	read_unlock_bh(&nd_tbl.lock);
> +
> +	return n;
> +}
> +
>  static void ndisc_recv_ns(struct sk_buff *skb)
>  {
>  	struct nd_msg *msg = (struct nd_msg *)skb_transport_header(skb);
> @@ -790,8 +804,8 @@ static void ndisc_recv_ns(struct sk_buff *skb)
>  		if (ipv6_chk_acast_addr(dev, &msg->target) ||
>  		    (idev->cnf.forwarding &&
>  		     (ipv6_devconf.proxy_ndp || idev->cnf.proxy_ndp) &&
> -		     (pneigh = pneigh_lookup(&nd_tbl, &init_net,
> -					     &msg->target, dev, 0)) != NULL)) {
> +		     (pneigh = neigh_check_router(dev, &msg->target,
> +						  &is_router)) != NULL)) {
>  			if (!(NEIGH_CB(skb)->flags & LOCALLY_ENQUEUED) &&
>  			    skb->pkt_type != PACKET_HOST &&
>  			    inc != 0 &&
> @@ -812,7 +826,7 @@ static void ndisc_recv_ns(struct sk_buff *skb)
>  			goto out;
>  	}
>  
> -	is_router = !!(pneigh ? pneigh->flags & NTF_ROUTER : idev->cnf.forwarding);
> +	is_router = !!(pneigh ? is_router : idev->cnf.forwarding);
>  
>  	if (dad) {
>  		struct in6_addr maddr;
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns.
  2008-03-11 13:24 ` Pavel Emelyanov
@ 2008-03-12  0:52   ` David Miller
  2008-03-12  9:41     ` [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2 Daniel Lezcano
  0 siblings, 1 reply; 10+ messages in thread
From: David Miller @ 2008-03-12  0:52 UTC (permalink / raw)
  To: xemul; +Cc: netdev

From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 11 Mar 2008 16:24:39 +0300

> You picked up the patch with /proc/net symlink, but skipped this
> one, while it was sent earlier. Is it _that_ bad :) ?

I am travelling and giving presentations in Japan, and
this patch is in my backlog to look at :-)

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2
  2008-03-12  0:52   ` David Miller
@ 2008-03-12  9:41     ` Daniel Lezcano
  2008-03-12 10:12       ` YOSHIFUJI Hideaki / 吉藤英明
  2008-03-12 10:30       ` Pavel Emelyanov
  0 siblings, 2 replies; 10+ messages in thread
From: Daniel Lezcano @ 2008-03-12  9:41 UTC (permalink / raw)
  To: David Miller; +Cc: xemul, netdev

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

David Miller wrote:
> From: Pavel Emelyanov <xemul@openvz.org>
> Date: Tue, 11 Mar 2008 16:24:39 +0300
> 
>> You picked up the patch with /proc/net symlink, but skipped this
>> one, while it was sent earlier. Is it _that_ bad :) ?
> 
> I am travelling and giving presentations in Japan, and
> this patch is in my backlog to look at :-)

The patch does not apply anymore due to the ndisc modification to be per 
namespace. I modified it to take the namespace into account and 
initialized the is_router variable to avoid a compilation warning.

[-- Attachment #2: ndisc_recv_ns-pneigh-race.patch --]
[-- Type: text/x-patch, Size: 4814 bytes --]

Subject: [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2
From: Pavel Emelyanov <xemul@openvz.org>

Proxy neighbors do not have any reference counting, so any caller
of pneigh_lookup (unless it's a netlink triggered add/del routine)
should _not_ perform any actions on the found proxy entry. 

There's one exception from this rule - the ipv6's ndisc_recv_ns() 
uses found entry to check the flags for NTF_ROUTER.

This creates a race between the ndisc and pneigh_delete - after 
the pneigh is returned to the caller, the nd_tbl.lock is dropped 
and the deleting procedure may proceed.

One of the fixes would be to add a reference counting, but this
problem exists for ndisc only. Besides such a patch would be too 
big for -rc4.

So I propose to introduce a __pneigh_lookup() which is supposed
to be called with the lock held and use it in ndisc code to check
the flags on alive pneigh entry. 

If this is OK, is there a real need in proxy neighbors reference
counting for 2.6.26  :)  ?

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

---
 include/net/neighbour.h |    2 ++
 net/core/neighbour.c    |   22 ++++++++++++++++++++++
 net/ipv6/ndisc.c        |   23 +++++++++++++++++++----
 3 files changed, 43 insertions(+), 4 deletions(-)

Index: net-2.6.26/include/net/neighbour.h
===================================================================
--- net-2.6.26.orig/include/net/neighbour.h
+++ net-2.6.26/include/net/neighbour.h
@@ -218,6 +218,8 @@ extern unsigned long		neigh_rand_reach_t
 extern void			pneigh_enqueue(struct neigh_table *tbl, struct neigh_parms *p,
 					       struct sk_buff *skb);
 extern struct pneigh_entry	*pneigh_lookup(struct neigh_table *tbl, struct net *net, const void *key, struct net_device *dev, int creat);
+extern struct pneigh_entry	*__pneigh_lookup(struct neigh_table *tbl,
+		struct net *net, const void *key, struct net_device *dev);
 extern int			pneigh_delete(struct neigh_table *tbl, struct net *net, const void *key, struct net_device *dev);
 
 extern void neigh_app_ns(struct neighbour *n);
Index: net-2.6.26/net/core/neighbour.c
===================================================================
--- net-2.6.26.orig/net/core/neighbour.c
+++ net-2.6.26/net/core/neighbour.c
@@ -466,6 +466,28 @@ out_neigh_release:
 	goto out;
 }
 
+struct pneigh_entry *__pneigh_lookup(struct neigh_table *tbl,
+		struct net *net, const void *pkey, struct net_device *dev)
+{
+	struct pneigh_entry *n;
+	int key_len = tbl->key_len;
+	u32 hash_val = *(u32 *)(pkey + key_len - 4);
+
+	hash_val ^= (hash_val >> 16);
+	hash_val ^= hash_val >> 8;
+	hash_val ^= hash_val >> 4;
+	hash_val &= PNEIGH_HASHMASK;
+
+	for (n = tbl->phash_buckets[hash_val]; n; n = n->next) {
+		if (!memcmp(n->key, pkey, key_len) &&
+		    (n->net == net) &&
+		    (n->dev == dev || !n->dev))
+			break;
+	}
+
+	return n;
+}
+
 struct pneigh_entry * pneigh_lookup(struct neigh_table *tbl,
 				    struct net *net, const void *pkey,
 				    struct net_device *dev, int creat)
Index: net-2.6.26/net/ipv6/ndisc.c
===================================================================
--- net-2.6.26.orig/net/ipv6/ndisc.c
+++ net-2.6.26/net/ipv6/ndisc.c
@@ -659,6 +659,21 @@ static void ndisc_solicit(struct neighbo
 	}
 }
 
+static struct pneigh_entry *neigh_check_router(struct net_device *dev,
+					       struct in6_addr *addr,
+					       int *is_router)
+{
+	struct pneigh_entry *n;
+
+	read_lock_bh(&nd_tbl.lock);
+	n = __pneigh_lookup(&nd_tbl, dev->nd_net, addr, dev);
+	if (n != NULL)
+		*is_router = (n->flags & NTF_ROUTER);
+	read_unlock_bh(&nd_tbl.lock);
+
+	return n;
+}
+
 static void ndisc_recv_ns(struct sk_buff *skb)
 {
 	struct nd_msg *msg = (struct nd_msg *)skb_transport_header(skb);
@@ -675,7 +690,7 @@ static void ndisc_recv_ns(struct sk_buff
 	struct pneigh_entry *pneigh = NULL;
 	int dad = ipv6_addr_any(saddr);
 	int inc;
-	int is_router;
+	int is_router = 0;
 
 	if (ipv6_addr_is_multicast(&msg->target)) {
 		ND_PRINTK2(KERN_WARNING
@@ -774,8 +789,8 @@ static void ndisc_recv_ns(struct sk_buff
 		if (ipv6_chk_acast_addr(dev, &msg->target) ||
 		    (idev->cnf.forwarding &&
 		     (ipv6_devconf.proxy_ndp || idev->cnf.proxy_ndp) &&
-		     (pneigh = pneigh_lookup(&nd_tbl, dev->nd_net,
-					     &msg->target, dev, 0)) != NULL)) {
+		     (pneigh =  neigh_check_router(dev, &msg->target,
+						   &is_router)) != NULL)) {
 			if (!(NEIGH_CB(skb)->flags & LOCALLY_ENQUEUED) &&
 			    skb->pkt_type != PACKET_HOST &&
 			    inc != 0 &&
@@ -796,7 +811,7 @@ static void ndisc_recv_ns(struct sk_buff
 			goto out;
 	}
 
-	is_router = !!(pneigh ? pneigh->flags & NTF_ROUTER : idev->cnf.forwarding);
+	is_router = !!(pneigh ? is_router : idev->cnf.forwarding);
 
 	if (dad) {
 		struct in6_addr maddr;

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2
  2008-03-12  9:41     ` [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2 Daniel Lezcano
@ 2008-03-12 10:12       ` YOSHIFUJI Hideaki / 吉藤英明
  2008-03-12 10:30       ` Pavel Emelyanov
  1 sibling, 0 replies; 10+ messages in thread
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2008-03-12 10:12 UTC (permalink / raw)
  To: dlezcano; +Cc: davem, xemul, netdev, yoshfuji

In article <47D7A52D.2090007@fr.ibm.com> (at Wed, 12 Mar 2008 10:41:01 +0100), Daniel Lezcano <dlezcano@fr.ibm.com> says:

> Subject: [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2
> From: Pavel Emelyanov <xemul@openvz.org>
> 
> Proxy neighbors do not have any reference counting, so any caller
> of pneigh_lookup (unless it's a netlink triggered add/del routine)
> should _not_ perform any actions on the found proxy entry. 

Good catch and I'm basically okay with this but, 
please rename neigh_check_router to pndisc_check_router().

Thanks.

--yoshfuji


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2
  2008-03-12  9:41     ` [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2 Daniel Lezcano
  2008-03-12 10:12       ` YOSHIFUJI Hideaki / 吉藤英明
@ 2008-03-12 10:30       ` Pavel Emelyanov
  2008-03-12 10:32         ` Daniel Lezcano
  1 sibling, 1 reply; 10+ messages in thread
From: Pavel Emelyanov @ 2008-03-12 10:30 UTC (permalink / raw)
  To: Daniel Lezcano; +Cc: David Miller, netdev

Daniel Lezcano wrote:
> David Miller wrote:
>> From: Pavel Emelyanov <xemul@openvz.org>
>> Date: Tue, 11 Mar 2008 16:24:39 +0300
>>
>>> You picked up the patch with /proc/net symlink, but skipped this
>>> one, while it was sent earlier. Is it _that_ bad :) ?
>> I am travelling and giving presentations in Japan, and
>> this patch is in my backlog to look at :-)
> 
> The patch does not apply anymore due to the ndisc modification to be per 
> namespace. I modified it to take the namespace into account and 
> initialized the is_router variable to avoid a compilation warning.
> 

My patch applies to net-2.6, while yours does not. 
Which tree is it for?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2
  2008-03-12 10:30       ` Pavel Emelyanov
@ 2008-03-12 10:32         ` Daniel Lezcano
  2008-03-12 10:40           ` Pavel Emelyanov
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Lezcano @ 2008-03-12 10:32 UTC (permalink / raw)
  To: Pavel Emelyanov; +Cc: David Miller, netdev

Pavel Emelyanov wrote:
> Daniel Lezcano wrote:
>> David Miller wrote:
>>> From: Pavel Emelyanov <xemul@openvz.org>
>>> Date: Tue, 11 Mar 2008 16:24:39 +0300
>>>
>>>> You picked up the patch with /proc/net symlink, but skipped this
>>>> one, while it was sent earlier. Is it _that_ bad :) ?
>>> I am travelling and giving presentations in Japan, and
>>> this patch is in my backlog to look at :-)
>> The patch does not apply anymore due to the ndisc modification to be per 
>> namespace. I modified it to take the namespace into account and 
>> initialized the is_router variable to avoid a compilation warning.
>>
> 
> My patch applies to net-2.6, while yours does not. 
> Which tree is it for?

well, hum, net-2.6.26 :|


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2
  2008-03-12 10:32         ` Daniel Lezcano
@ 2008-03-12 10:40           ` Pavel Emelyanov
  2008-03-12 10:41             ` Daniel Lezcano
  0 siblings, 1 reply; 10+ messages in thread
From: Pavel Emelyanov @ 2008-03-12 10:40 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: David Miller, netdev,
	YOSHIFUJI Hideaki / 吉藤英明

Daniel Lezcano wrote:
> Pavel Emelyanov wrote:
>> Daniel Lezcano wrote:
>>> David Miller wrote:
>>>> From: Pavel Emelyanov <xemul@openvz.org>
>>>> Date: Tue, 11 Mar 2008 16:24:39 +0300
>>>>
>>>>> You picked up the patch with /proc/net symlink, but skipped this
>>>>> one, while it was sent earlier. Is it _that_ bad :) ?
>>>> I am travelling and giving presentations in Japan, and
>>>> this patch is in my backlog to look at :-)
>>> The patch does not apply anymore due to the ndisc modification to be per 
>>> namespace. I modified it to take the namespace into account and 
>>> initialized the is_router variable to avoid a compilation warning.
>>>
>> My patch applies to net-2.6, while yours does not. 
>> Which tree is it for?
> 
> well, hum, net-2.6.26 :|

OK. 
Then I will fix the comments from YOSHIFUJI and re-send the patch for net-2.6.

Thanks,
Pavel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2
  2008-03-12 10:40           ` Pavel Emelyanov
@ 2008-03-12 10:41             ` Daniel Lezcano
  0 siblings, 0 replies; 10+ messages in thread
From: Daniel Lezcano @ 2008-03-12 10:41 UTC (permalink / raw)
  To: Pavel Emelyanov
  Cc: David Miller, netdev,
	YOSHIFUJI Hideaki / 吉藤英明

Pavel Emelyanov wrote:
> Daniel Lezcano wrote:
>> Pavel Emelyanov wrote:
>>> Daniel Lezcano wrote:
>>>> David Miller wrote:
>>>>> From: Pavel Emelyanov <xemul@openvz.org>
>>>>> Date: Tue, 11 Mar 2008 16:24:39 +0300
>>>>>
>>>>>> You picked up the patch with /proc/net symlink, but skipped this
>>>>>> one, while it was sent earlier. Is it _that_ bad :) ?
>>>>> I am travelling and giving presentations in Japan, and
>>>>> this patch is in my backlog to look at :-)
>>>> The patch does not apply anymore due to the ndisc modification to be per 
>>>> namespace. I modified it to take the namespace into account and 
>>>> initialized the is_router variable to avoid a compilation warning.
>>>>
>>> My patch applies to net-2.6, while yours does not. 
>>> Which tree is it for?
>> well, hum, net-2.6.26 :|
> 
> OK. 
> Then I will fix the comments from YOSHIFUJI and re-send the patch for net-2.6.

Ok, sorry for the confusion.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns.
  2008-03-06 11:18 [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns Pavel Emelyanov
  2008-03-11 13:24 ` Pavel Emelyanov
@ 2008-03-24  4:49 ` David Miller
  1 sibling, 0 replies; 10+ messages in thread
From: David Miller @ 2008-03-24  4:49 UTC (permalink / raw)
  To: xemul; +Cc: netdev

From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 06 Mar 2008 14:18:05 +0300

> +struct pneigh_entry *__pneigh_lookup(struct neigh_table *tbl,
> +		struct net *net, const void *pkey, struct net_device *dev)
> +{

You don't export this to modules, so when IPV6 is modular
the build fails.

Please fix this up and resubmit, thanks.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2008-03-24  4:49 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-06 11:18 [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns Pavel Emelyanov
2008-03-11 13:24 ` Pavel Emelyanov
2008-03-12  0:52   ` David Miller
2008-03-12  9:41     ` [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns - V2 Daniel Lezcano
2008-03-12 10:12       ` YOSHIFUJI Hideaki / 吉藤英明
2008-03-12 10:30       ` Pavel Emelyanov
2008-03-12 10:32         ` Daniel Lezcano
2008-03-12 10:40           ` Pavel Emelyanov
2008-03-12 10:41             ` Daniel Lezcano
2008-03-24  4:49 ` [PATCH][NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).