From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
mingo@kernel.org, rusty@rustcorp.com.au, oleg@redhat.com,
linux-kernel@vger.kernel.org, andi@firstfloor.org,
rostedt@goodmis.org, tglx@linutronix.de,
Michel Lespinasse <walken@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
David Woodhouse <David.Woodhouse@intel.com>,
Rik van Riel <riel@redhat.com>
Subject: Re: [RFC][PATCH 6/9] seqlock: Better document raw_write_seqcount_latch()
Date: Mon, 2 Mar 2015 11:46:13 -0800 [thread overview]
Message-ID: <20150302194613.GV15405@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150302085116.GD24151@twins.programming.kicks-ass.net>
On Mon, Mar 02, 2015 at 09:51:16AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 02, 2015 at 09:33:20AM +0100, Peter Zijlstra wrote:
> > On Sun, Mar 01, 2015 at 02:02:23PM +0000, Mathieu Desnoyers wrote:
>
> > > The latch, AFAIU, takes care of making sure the new objects are
> > > initialized before being published into the data structure, so there
> > > would be no need to use RCU assign pointer. However, we really need
> > > RCU around reads, along with a grace period between removal of an object
> > > and its teardown.
> >
> > So I do need the rcu_assign_pointer for the RB link because that also
> > initializes the rb_node itself. Or put differently, be _very_ _VERY_
> > sure your entire object is initialized before the latch.
> >
> > Secondly, note that the latch does a WMB and rcu_assign_pointer does a
> > RELEASE, these are not equivalent.
> >
> > So I don't think I will highlight this particular point. If you're sure
> > enough to know the difference you can get away with it, sure. But in
> > general I think people should still use rcu_assign_pointer; if only to
> > make Paul sleep better at night ;-)
I do appreciate that sentiment. ;-)
> Also note that if you do not use rcu_assign_pointer() one will at the
> very least require WRITE_ONCE().
And, for ARM, IA64, and PowerPC, memory-barrier instructions.
Thanx, Paul
next prev parent reply other threads:[~2015-03-02 19:46 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-28 21:24 [RFC][PATCH 0/9] latched RB-trees and __module_address() Peter Zijlstra
2015-02-28 21:24 ` [RFC][PATCH 1/9] klp: Fix obvious RCU fail Peter Zijlstra
2015-03-01 20:09 ` Jiri Kosina
2015-03-02 8:35 ` Peter Zijlstra
2015-03-02 9:13 ` Jiri Kosina
2015-03-02 10:00 ` Peter Zijlstra
2015-03-02 9:21 ` Petr Mladek
2015-03-02 1:31 ` Masami Hiramatsu
2015-03-02 19:21 ` Paul E. McKenney
2015-03-02 21:07 ` Josh Poimboeuf
2015-02-28 21:24 ` [RFC][PATCH 2/9] module: Sanitize RCU usage and locking Peter Zijlstra
2015-03-02 11:16 ` Rusty Russell
2015-03-02 12:37 ` Peter Zijlstra
2015-03-02 19:37 ` Paul E. McKenney
2015-03-17 17:13 ` Peter Zijlstra
2015-02-28 21:24 ` [RFC][PATCH 3/9] module: Annotate module version magic Peter Zijlstra
2015-03-02 19:38 ` Paul E. McKenney
2015-02-28 21:24 ` [RFC][PATCH 4/9] module, jump_label: Fix module locking Peter Zijlstra
2015-03-02 19:39 ` Paul E. McKenney
2015-02-28 21:24 ` [RFC][PATCH 5/9] rbtree: Make lockless searches non-fatal Peter Zijlstra
2015-03-01 13:52 ` Mathieu Desnoyers
2015-03-02 8:27 ` Peter Zijlstra
2015-03-01 21:11 ` Michel Lespinasse
2015-03-02 7:46 ` Ingo Molnar
2015-03-02 8:23 ` Peter Zijlstra
2015-03-02 9:53 ` Peter Zijlstra
2015-02-28 21:24 ` [RFC][PATCH 6/9] seqlock: Better document raw_write_seqcount_latch() Peter Zijlstra
2015-03-01 14:02 ` Mathieu Desnoyers
2015-03-02 8:33 ` Peter Zijlstra
2015-03-02 8:51 ` Peter Zijlstra
2015-03-02 19:46 ` Paul E. McKenney [this message]
2015-03-01 21:12 ` Michel Lespinasse
2015-02-28 21:24 ` [RFC][PATCH 7/9] rbtree: Implement generic latch_tree Peter Zijlstra
2015-03-01 21:17 ` Michel Lespinasse
2015-03-02 8:05 ` Peter Zijlstra
2015-03-02 19:53 ` Paul E. McKenney
2015-03-17 17:24 ` Peter Zijlstra
2015-02-28 21:24 ` [RFC][PATCH 8/9] module: Optimize __module_address() using a latched RB-tree Peter Zijlstra
2015-02-28 21:24 ` [RFC][PATCH 9/9] module: Use __module_address() for module_address_lookup() Peter Zijlstra
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=20150302194613.GV15405@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=David.Woodhouse@intel.com \
--cc=aarcange@redhat.com \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=walken@google.com \
/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.