Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754423Ab3JLCZN (ORCPT ); Fri, 11 Oct 2013 22:25:13 -0400 Received: from order.stressinduktion.org ([87.106.68.36]:57138 "EHLO order.stressinduktion.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751393Ab3JLCZL (ORCPT ); Fri, 11 Oct 2013 22:25:11 -0400 Date: Sat, 12 Oct 2013 04:25:08 +0200 From: Hannes Frederic Sowa To: "Paul E. McKenney" Cc: Eric Dumazet , Josh Triplett , linux-kernel@vger.kernel.org, mingo@kernel.org, laijs@cn.fujitsu.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, darren@dvhart.com, fweisbec@gmail.com, sbw@mit.edu, "David S. Miller" , Alexey Kuznetsov , James Morris , Hideaki YOSHIFUJI , Patrick McHardy , netdev@vger.kernel.org Subject: Re: [PATCH v2 tip/core/rcu 07/13] ipv6/ip6_tunnel: Apply rcu_access_pointer() to avoid sparse false positive Message-ID: <20131012022508.GA20321@order.stressinduktion.org> Mail-Followup-To: "Paul E. McKenney" , Eric Dumazet , Josh Triplett , linux-kernel@vger.kernel.org, mingo@kernel.org, laijs@cn.fujitsu.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, darren@dvhart.com, fweisbec@gmail.com, sbw@mit.edu, "David S. Miller" , Alexey Kuznetsov , James Morris , Hideaki YOSHIFUJI , Patrick McHardy , netdev@vger.kernel.org References: <1381356624.4971.26.camel@edumazet-glaptop.roam.corp.google.com> <20131009223652.GC5790@linux.vnet.ibm.com> <1381359077.4971.37.camel@edumazet-glaptop.roam.corp.google.com> <20131009225617.GH11709@jtriplet-mobl1> <1381360675.4971.45.camel@edumazet-glaptop.roam.corp.google.com> <20131009234040.GB14055@jtriplet-mobl1> <1381363960.4971.55.camel@edumazet-glaptop.roam.corp.google.com> <20131010002833.GJ5790@linux.vnet.ibm.com> <20131010020422.GB24368@order.stressinduktion.org> <20131010190532.GQ5790@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20131010190532.GQ5790@linux.vnet.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3706 Lines: 89 On Thu, Oct 10, 2013 at 12:05:32PM -0700, Paul E. McKenney wrote: > On Thu, Oct 10, 2013 at 04:04:22AM +0200, Hannes Frederic Sowa wrote: > > On Wed, Oct 09, 2013 at 05:28:33PM -0700, Paul E. McKenney wrote: > > > On Wed, Oct 09, 2013 at 05:12:40PM -0700, Eric Dumazet wrote: > > > > On Wed, 2013-10-09 at 16:40 -0700, Josh Triplett wrote: > > > > > > > > > that. Constructs like list_del_rcu are much clearer, and not > > > > > open-coded. Open-coding synchronization code is almost always a Bad > > > > > Idea. > > > > > > > > OK, so you think there is synchronization code. > > > > > > > > I will shut up then, no need to waste time. > > > > > > As you said earlier, we should at least get rid of the memory barrier > > > as long as we are changing the code. > > > > Interesting thread! > > > > Sorry to chime in and asking a question: > > > > Why do we need an ACCESS_ONCE here if rcu_assign_pointer can do without one? > > In other words I wonder why rcu_assign_pointer is not a static inline function > > to use the sequence point in argument evaluation (if I remember correctly this > > also holds for inline functions) to not allow something like this: > > > > E.g. we want to publish which lock to take first to prevent an ABBA problem > > (extreme example): > > > > rcu_assign_pointer(lockptr, min(lptr1, lptr2)); > > > > Couldn't a compiler spill the lockptr memory location as a temporary buffer > > if the compiler is under register pressure? (yes, this seems unlikely if we > > flushed out most registers to memory because of the barrier, but still... ;) ) > > > > This seems to be also the case if we publish a multi-dereferencing pointers > > e.g. ptr->ptr->ptr. > > IIRC, sequence points only confine volatile accesses. For non-volatile > accesses, the so-called "as-if rule" allows compiler writers to do some > surprisingly global reordering. > > The reason that rcu_assign_pointer() isn't an inline function is because > it needs to be type-generic, in other words, it needs to be OK to use > it on any type of pointers as long as the C types of the two pointers > match (the sparse types can vary a bit). > > One of the reasons for wanting a volatile cast in rcu_assign_pointer() is > to prevent compiler mischief such as you described in your last two > paragraphs. That said, it would take a very brave compiler to pull > a pointer-referenced memory location into a register and keep it there. > Unfortunately, increasing compiler bravery seems to be a solid long-term > trend. I saw your patch regarding making rcu_assign_pointer volatile and wonder if we can still make it a bit more safe to use if we force the evaluation of the to-be-assigned pointer before the write barrier. This is what I have in mind: diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index f1f1bc3..79eccc3 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -550,8 +550,9 @@ static inline void rcu_preempt_sleep_check(void) }) #define __rcu_assign_pointer(p, v, space) \ do { \ + typeof(v) ___v = (v); \ smp_wmb(); \ - (p) = (typeof(*v) __force space *)(v); \ + (p) = (typeof(*___v) __force space *)(___v); \ } while (0) I don't think ___v must be volatile for this case because the memory barrier will force the evaluation of v first. This would guard against cases where rcu_assign_pointer is used like: rcu_assign_pointer(ptr, compute_ptr_with_side_effects()); Greetings, Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/