[PATCH] Ipv6: Delete rcu_read_lock

From: Roy.Li <redacted>

Delete rcu_read_lock, it is redundant.

Signed-off-by: Roy.Li <redacted>
---
 net/ipv6/ndisc.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 9da6e02..dd633ff 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c

@@ -370,17 +370,14 @@ static int ndisc_constructor(struct neighbour *neigh)
 	struct neigh_parms *parms;
 	int is_multicast = ipv6_addr_is_multicast(addr);
 
-	rcu_read_lock();
 	in6_dev = in6_dev_get(dev);
 	if (in6_dev == NULL) {
-		rcu_read_unlock();
 		return -EINVAL;
 	}
 
 	parms = in6_dev->nd_parms;
 	__neigh_parms_put(neigh->parms);
 	neigh->parms = neigh_parms_clone(parms);
-	rcu_read_unlock();
 
 	neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST;
 	if (!dev->header_ops) {

-- 
1.7.1

On Thu, Sep 29, 2011 at 3:46 PM,  [off-list ref] wrote:

I think the rcu_read_lock protects in6_dev->nd_parms.

Yan, Zheng

On 09/29/2011 04:16 PM, Yan, Zheng wrote:

I think the rcu_read_lock protects in6_dev->nd_parms.

It can not protect in6_dev->nd_parms.

rcu_read_lock protects the data which is accessed by rcu_XXX,


-Roy

Yan, Zheng

-- 
Best Reagrds,
Roy | RongQing Li

Le jeudi 29 septembre 2011 à 15:46 +0800, rongqing.li@windriver.com a
écrit :

From: Roy.Li <redacted>

Delete rcu_read_lock, it is redundant.

A good changelog and patch title are required.

Something like :

[PATCH net-next] ipv6: remove a rcu_read_lock in ndisc_constructor

in6_dev_get(dev) takes a reference on struct inet6_dev, we dont need rcu
locking in ndisc_constructor()



-----

Or, you could try to really use RCU and not take a reference (ie, use 
__in6_dev_get() instead of in6_dev_get(dev).


Untested patch :

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 9da6e02..a4f4472 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c

@@ -371,7 +371,7 @@ static int ndisc_constructor(struct neighbour *neigh)
 	int is_multicast = ipv6_addr_is_multicast(addr);
 
 	rcu_read_lock();
-	in6_dev = in6_dev_get(dev);
+	in6_dev = __in6_dev_get(dev);
 	if (in6_dev == NULL) {
 		rcu_read_unlock();
 		return -EINVAL;

@@ -380,7 +380,6 @@ static int ndisc_constructor(struct neighbour *neigh)
 	parms = in6_dev->nd_parms;
 	__neigh_parms_put(neigh->parms);
 	neigh->parms = neigh_parms_clone(parms);
-	rcu_read_unlock();
 
 	neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST;
 	if (!dev->header_ops) {

@@ -409,7 +408,7 @@ static int ndisc_constructor(struct neighbour *neigh)
 		else
 			neigh->output = neigh->ops->output;
 	}
-	in6_dev_put(in6_dev);
+	rcu_read_unlock();
 	return 0;
 }
 

On 09/29/2011 04:44 PM, Eric Dumazet wrote:

A good changelog and patch title are required.

Something like :

[PATCH net-next] ipv6: remove a rcu_read_lock in ndisc_constructor

in6_dev_get(dev) takes a reference on struct inet6_dev, we dont need rcu
locking in ndisc_constructor()

Thank you, I will resend it.

-Roy

On Thu, Sep 29, 2011 at 4:25 PM, Rongqing Li [off-list ref] wrote:

On 09/29/2011 04:16 PM, Yan, Zheng wrote:

quoted

I think the rcu_read_lock protects in6_dev->nd_parms.

It can not protect in6_dev->nd_parms.

rcu_read_lock protects the data which is accessed by rcu_XXX,

I'm confused, why does neigh_parms_release() use call_rcu() to release nd_parms.

On 09/29/2011 04:52 PM, Yan, Zheng wrote:

On Thu, Sep 29, 2011 at 4:25 PM, Rongqing Li[off-list ref]  wrote:

quoted

On 09/29/2011 04:16 PM, Yan, Zheng wrote:

quoted

I think the rcu_read_lock protects in6_dev->nd_parms.

It can not protect in6_dev->nd_parms.

rcu_read_lock protects the data which is accessed by rcu_XXX,

I'm confused, why does neigh_parms_release() use call_rcu() to release nd_parms.

Same as idev, there is a reference on struct neigh_parms
which protects them

-Roy