Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections

2 messages, 2 authors, 2005-09-30 · open the first message on its own page

Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections

From: Paul E. McKenney <hidden>
Date: 2005-09-30 00:23:09

On Thu, Sep 29, 2005 at 04:30:28PM -0700, Suzanne Wood wrote:
quoted
Date: Fri, 30 Sep 2005 07:28:36 +1000
From: Herbert Xu <herbert@gondor.apana.org.au>
quoted
On Thu, Sep 29, 2005 at 09:02:29AM -0700, Suzanne Wood wrote:
quoted
The exchange below suggests that it is equally important 
to have the rcu_dereference() in __in_dev_get(), so the 
idea of the only difference between in_dev_get and 
__in_dev_get being the refcnt may be accepted.
quoted
With __in_dev_get() it's the caller's responsibility to ensure
that RCU works correctly.  Therefore if any rcu_dereference is
needed it should be done by the caller.
This sounds reasonable to me.  Does everyone agree? 
Is there any case where __in_dev_get() might be called without
needing to be wrapped with rcu_dereference()?  If so, then I
agree (FWIW, given my meagre knowledge of Linux networking).

If all __in_dev_get() invocations need to be wrapped in
rcu_dereference(), then it seems to me that there would be
motivation to bury rcu_dereference() in __in_dev_get().
quoted
Some callers of __in_dev_get() don't need rcu_dereference at all
because they're protected by the rtnl.
quoted
BTW, could you please move the rcu_dereference in in_dev_get()
into the if clause? The barrier is not needed when ip_ptr is
NULL.
The trouble with that may be that there are three events, the
dereference, the assignment, and the conditional test.  The
rcu_dereference() is meant to assure deferred destruction
throughout.
One only needs an rcu_dereference() once on the data-flow path from
fetching the RCU-protected pointer to dereferencing that pointer.
If the pointer is NULL, there is no way you can dereference it,
so, technically, Herbert is quite correct.

However, rcu_dereference() only generates a memory barrier on DEC
Alpha, so there is normally no penalty for using it in the NULL-pointer
case.  So, when using rcu_dereference() unconditionally simplifies
the code, it may make sense to "just do it".

							Thanx, Paul

Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2005-09-30 00:27:19

On Thu, Sep 29, 2005 at 05:23:46PM -0700, Paul E. McKenney wrote:
Is there any case where __in_dev_get() might be called without
needing to be wrapped with rcu_dereference()?  If so, then I
agree (FWIW, given my meagre knowledge of Linux networking).
Yes.  All paths that call __in_dev_get() under the rtnl do not
need rcu_dereference (or any RCU at all) since the rtnl prevents
any ip_ptr modification from occuring.
However, rcu_dereference() only generates a memory barrier on DEC
Alpha, so there is normally no penalty for using it in the NULL-pointer
case.  So, when using rcu_dereference() unconditionally simplifies
the code, it may make sense to "just do it".
Here is what the code would look like:

	rcu_read_lock();
	in_dev = dev->ip_ptr;
	if (in_dev) {
		in_dev = rcu_dereference(in_dev);
		atomic_inc(&in_dev->refcnt);
	}
	rcu_read_unlock();
	return in_dev;

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help