All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	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" <davem@davemloft.net>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	James Morris <jmorris@namei.org>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	Patrick McHardy <kaber@trash.net>,
	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
Date: Fri, 11 Oct 2013 06:25:12 -0700	[thread overview]
Message-ID: <20131011132512.GW5790@linux.vnet.ibm.com> (raw)
In-Reply-To: <20131011002044.GA32546@jtriplet-mobl1>

On Thu, Oct 10, 2013 at 05:20:44PM -0700, Josh Triplett 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.
> > 
> > Josh, what would you suggest as the best way to avoid the memory barrier,
> > keep sparse happy, and not be too ugly?
> 
> The more I think about it, the more I realize that assigning an __rcu
> pointer to an __rcu pointer *without* a memory barrier is a sufficiently
> uncommon case that you probably *should* just write an open-coded
> assignment.  Just please put a very clear comment right before it.

Fair enough, will do!  Given earlier email, I believe that Eric is
fine with this, and if he isn't I am sure he will let us know.  ;-)

> I'd originally thought it might make sense to have a macro similar to
> rcu_assign_pointer, but I just don't think this is a common enough case,
> and we don't want people thinking they can use this in general for __rcu
> to __rcu assignments (most of which still need a memory barrier).

Yep, it is a rather small fraction of rcu_assign_pointer() instances.

							Thanx, Paul


  reply	other threads:[~2013-10-11 13:25 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-09 21:29 [Bridge] [PATCH v2 tip/core/rcu 0/13] Sparse-related updates for 3.13 Paul E. McKenney
2013-10-09 21:29 ` Paul E. McKenney
2013-10-09 21:29 ` Paul E. McKenney
2013-10-09 21:29 ` [PATCH v2 tip/core/rcu 01/13] rcu: Make rcu_assign_pointer's assignment volatile and type-safe Paul E. McKenney
2013-10-09 21:29   ` [PATCH v2 tip/core/rcu 02/13] notifiers: Apply rcu_access_pointer() to avoid sparse false positive Paul E. McKenney
2013-10-09 21:29   ` [Bridge] [PATCH v2 tip/core/rcu 03/13] bridge: " Paul E. McKenney
2013-10-09 21:29     ` Paul E. McKenney
2013-10-09 21:29     ` Paul E. McKenney
2013-10-09 21:29   ` [Bridge] [PATCH v2 tip/core/rcu 04/13] wireless: " Paul E. McKenney
2013-10-09 21:29     ` Paul E. McKenney
2013-10-09 21:29   ` [PATCH v2 tip/core/rcu 05/13] decnet: " Paul E. McKenney
2013-10-09 22:28     ` Josh Triplett
2013-10-09 22:46       ` Paul E. McKenney
2013-10-09 22:57         ` Josh Triplett
2013-10-09 23:57           ` Paul E. McKenney
2013-10-09 22:58     ` Dhaval Giani
2013-10-09 23:54       ` Paul E. McKenney
2013-10-09 21:29   ` [PATCH v2 tip/core/rcu 06/13] ipv4/ip_socketglue: " Paul E. McKenney
2013-10-09 21:29   ` [PATCH v2 tip/core/rcu 07/13] ipv6/ip6_tunnel: " Paul E. McKenney
2013-10-09 21:42     ` Eric Dumazet
2013-10-09 21:57       ` Paul E. McKenney
2013-10-09 22:10         ` Eric Dumazet
2013-10-09 22:36           ` Paul E. McKenney
2013-10-09 22:51             ` Eric Dumazet
2013-10-09 22:56               ` Josh Triplett
2013-10-09 23:17                 ` Eric Dumazet
2013-10-09 23:40                   ` Josh Triplett
2013-10-10  0:12                     ` Eric Dumazet
2013-10-10  0:28                       ` Paul E. McKenney
2013-10-10  2:04                         ` Hannes Frederic Sowa
2013-10-10 19:05                           ` Paul E. McKenney
2013-10-12  2:25                             ` Hannes Frederic Sowa
2013-10-12  7:53                               ` Paul E. McKenney
2013-10-12 16:43                                 ` Hannes Frederic Sowa
2013-10-12 17:37                                   ` Hannes Frederic Sowa
2013-10-12 19:42                                     ` Mathieu Desnoyers
2013-10-13 11:14                                       ` Paul E. McKenney
2013-10-13 20:11                                         ` Hannes Frederic Sowa
2013-10-11  0:20                         ` Josh Triplett
2013-10-11 13:25                           ` Paul E. McKenney [this message]
2013-10-09 21:29   ` [PATCH v2 tip/core/rcu 08/13] ipv6/ip6_gre: " Paul E. McKenney
2013-10-09 21:29   ` [PATCH v2 tip/core/rcu 09/13] ipv6/sit: " Paul E. McKenney
2013-10-09 21:29   ` [PATCH v2 tip/core/rcu 10/13] mac80211: " Paul E. McKenney
2013-10-09 21:29   ` [Bridge] [PATCH v2 tip/core/rcu 11/13] bridge/br_mdb: " Paul E. McKenney
2013-10-09 21:29     ` Paul E. McKenney
2013-10-09 21:29     ` Paul E. McKenney
2013-10-09 21:29   ` [Bridge] [PATCH v2 tip/core/rcu 12/13] bonding/bond_main: " Paul E. McKenney
2013-10-09 21:29     ` Paul E. McKenney
2013-10-09 21:29     ` Paul E. McKenney
2013-10-09 21:29   ` [PATCH v2 tip/core/rcu 13/13] bonding/bond_alb.c: " Paul E. McKenney
2013-10-09 22:26   ` [PATCH v2 tip/core/rcu 01/13] rcu: Make rcu_assign_pointer's assignment volatile and type-safe Josh Triplett
2013-10-09 22:18 ` [Bridge] [PATCH v2 tip/core/rcu 0/13] Sparse-related updates for 3.13 Josh Triplett
2013-10-09 22:18   ` Josh Triplett
2013-10-09 22:46   ` [Bridge] " Paul E. McKenney
2013-10-09 22:46     ` Paul E. McKenney
2013-10-09 22:46     ` Paul E. McKenney
2013-10-09 22:23 ` [Bridge] " Josh Triplett
2013-10-09 22:23   ` Josh Triplett
2013-10-09 22:30 ` [Bridge] " Josh Triplett
2013-10-09 22:30   ` Josh Triplett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131011132512.GW5790@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=darren@dvhart.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=jmorris@namei.org \
    --cc=josh@joshtriplett.org \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=niv@us.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sbw@mit.edu \
    --cc=tglx@linutronix.de \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.