On 05/28/2015 06:13 PM, Eric Dumazet wrote:
This patch is not needed.
You really should read Documentation/RCU , because it looks like you are
quite confused.
When we remove an element from a RCU protected list, all the objects in
the chain are already ready to be caught by rcu readers.
On Fri, 2015-05-29 at 09:21 +0800, Ying Xue wrote:
On 05/28/2015 06:13 PM, Eric Dumazet wrote:
This patch is not needed.
You really should read Documentation/RCU , because it looks like you are
quite confused.
When we remove an element from a RCU protected list, all the objects in
Commit e4c4e448cf55 (neigh: Convert garbage collection from softirq
to workqueue) misses to use rcu_assign_pointer() macro to assign a
RCU-protected pointer.
Signed-off-by: Ying Xue ying@windriver.com
---
net/core/neighbour.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
On Thu, 2015-05-28 at 16:28 +0800, Ying Xue wrote:
Commit e4c4e448cf55 (neigh: Convert garbage collection from softirq
to workqueue) misses to use rcu_assign_pointer() macro to assign a
RCU-protected pointer.
Signed-off-by: Ying Xue ying@windriver.com
---
net/core/neighbour.c |3
On Thu, 2015-05-28 at 21:50 +0800, Herbert Xu wrote:
This patch is indeed bogus but accessing an RCU-protected like
this will trigger sparse warnings. So better make it an
RCU_INIT_POINTER.
A = B; is perfectly fine since both A and B have the same __rcu
attribute.
Sparse has no warning
Eric Dumazet eric.duma...@gmail.com wrote:
This patch is not needed.
You really should read Documentation/RCU , because it looks like you are
quite confused.
When we remove an element from a RCU protected list, all the objects in
the chain are already ready to be caught by rcu readers.
