From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: NeilBrown <neilb@suse.com>,
Trond Myklebust <trond.myklebust@primarydata.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
linux-nfs@vger.kernel.org, Lai Jiangshan <jiangshanlai@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] rculist: add list_for_each_entry_from_rcu()
Date: Mon, 30 Apr 2018 06:43:08 -0700 [thread overview]
Message-ID: <20180430134308.GT26088@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180430052032.GA16963@localhost>
On Sun, Apr 29, 2018 at 10:20:33PM -0700, Josh Triplett wrote:
> On Mon, Apr 30, 2018 at 02:31:30PM +1000, NeilBrown wrote:
> > list_for_each_entry_from_rcu() is an RCU version of
> > list_for_each_entry_from(). It walks a linked list under rcu
> > protection, from a given start point.
> >
> > It is similar to list_for_each_entry_continue_rcu() but starts *at*
> > the given position rather than *after* it.
> >
> > Naturally, the start point must be known to be in the list.
>
> I'd suggest giving an explicit advisory comment to clarify and suggest
> correct usage:
>
> "This would typically require either that you obtained the node from a
> previous walk of the list in the same RCU read-side critical section, or
> that you held some sort of non-RCU reference (such as a reference count)
> to keep the node alive *and* in the list."
>
> (Feel free to wordsmith the exact wording, but something like that seems
> like it would help people understand how to use this correctly, and make
> it less likely that they'd use it incorrectly.)
What Josh said! Could you also contrast this with the existing
list_for_each_entry_continue_rcu() macro in the header comment as well
as in the commit log?
Thanx, Paul
next prev parent reply other threads:[~2018-04-30 13:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 4:31 [PATCH 0/4 V2] Avoid quadratic search when freeing delegations NeilBrown
2018-04-30 4:31 ` [PATCH 1/4] NFS: slight optimization for walking list for delegations NeilBrown
2018-04-30 15:17 ` Steven Rostedt
2018-05-31 5:23 ` [PATCH 1/4 v2] " NeilBrown
2018-06-04 21:31 ` Steven Rostedt
2018-04-30 4:31 ` [PATCH 3/4] rculist: add list_for_each_entry_from_rcu() NeilBrown
2018-04-30 5:20 ` Josh Triplett
2018-04-30 13:43 ` Paul E. McKenney [this message]
2018-04-30 15:14 ` Steven Rostedt
2018-04-30 15:35 ` Paul E. McKenney
2018-05-01 3:11 ` [PATCH 3/4 v2] " NeilBrown
2018-05-01 14:14 ` Paul E. McKenney
2018-05-01 21:34 ` NeilBrown
2018-04-30 4:31 ` [PATCH 2/4] NFS: use cond_resched() when restarting walk of delegation list NeilBrown
2018-04-30 4:31 ` [PATCH 4/4] NFS: Avoid quadratic search when freeing delegations NeilBrown
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=20180430134308.GT26088@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=anna.schumaker@netapp.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neilb@suse.com \
--cc=rostedt@goodmis.org \
--cc=trond.myklebust@primarydata.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.