All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: mingo@kernel.org, andrii@kernel.org, oleg@redhat.com,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	rostedt@goodmis.org, mhiramat@kernel.org, jolsa@kernel.org,
	clm@meta.com, paulmck@kernel.org
Subject: Re: [PATCH v2 03/11] rbtree: Provide rb_find_rcu() / rb_find_add_rcu()
Date: Mon, 15 Jul 2024 13:21:35 +0200	[thread overview]
Message-ID: <20240715112135.GC14400@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CAEf4BzZLW+Dez6-WOe1jtCEjC8n6vUqcewWAYViquT4Cc6AA0Q@mail.gmail.com>

On Fri, Jul 12, 2024 at 01:23:43PM -0700, Andrii Nakryiko wrote:
> On Thu, Jul 11, 2024 at 4:07 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > Much like latch_tree, add two RCU methods for the regular RB-tree,
> > which can be used in conjunction with a seqcount to provide lockless
> > lookups.
> >
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> > ---
> >  include/linux/rbtree.h |   67 +++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 67 insertions(+)
> >
> > --- a/include/linux/rbtree.h
> > +++ b/include/linux/rbtree.h
> > @@ -245,6 +245,42 @@ rb_find_add(struct rb_node *node, struct
> >  }
> >
> >  /**
> > + * rb_find_add_rcu() - find equivalent @node in @tree, or add @node
> > + * @node: node to look-for / insert
> > + * @tree: tree to search / modify
> > + * @cmp: operator defining the node order
> > + *
> > + * Adds a Store-Release for link_node.
> > + *
> > + * Returns the rb_node matching @node, or NULL when no match is found and @node
> > + * is inserted.
> > + */
> > +static __always_inline struct rb_node *
> > +rb_find_add_rcu(struct rb_node *node, struct rb_root *tree,
> > +               int (*cmp)(struct rb_node *, const struct rb_node *))
> 
> I don't get the point of the RCU version of rb_find_add as RCU itself
> doesn't provide enough protection for modification of the tree, right?
> So in uprobes code you do rb_find_add_rcu() under uprobes_treelock +
> uprobes_seqcount locks. Wouldn't it be just as fine to do plain
> non-RCU rb_find_add() in that case? After all, you do plain rb_erase
> under the same set of locks.
> 
> So what's the point of this one?

The store-release when adding it to the tree. Without that it becomes
possible to find the entry while the entry itself is incomplete.

Eg. something like:

 entry.foo = A
 rb_find_add(&entry->node, &my_tree, my_cmp);

vs

 rcu_read_lock();
 entry = rb_find_rcu(...);
 assert(entry->foo == A);

might fail. Because there is nothing ordering the foo store and the
rb-node add.



  reply	other threads:[~2024-07-15 11:21 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-11 11:02 [PATCH v2 00/11] perf/uprobe: Optimize uprobes Peter Zijlstra
2024-07-11 11:02 ` [PATCH v2 01/11] perf/uprobe: Re-indent labels Peter Zijlstra
2024-07-11 11:58   ` Jiri Olsa
2024-07-11 12:07     ` Peter Zijlstra
2024-07-11 11:02 ` [PATCH v2 02/11] perf/uprobe: Remove spurious whitespace Peter Zijlstra
2024-07-11 11:02 ` [PATCH v2 03/11] rbtree: Provide rb_find_rcu() / rb_find_add_rcu() Peter Zijlstra
2024-07-12 20:23   ` Andrii Nakryiko
2024-07-15 11:21     ` Peter Zijlstra [this message]
2024-07-15 17:13       ` Andrii Nakryiko
2024-07-11 11:02 ` [PATCH v2 04/11] perf/uprobe: RCU-ify find_uprobe() Peter Zijlstra
2024-07-11 13:59   ` Masami Hiramatsu
2024-07-11 11:02 ` [PATCH v2 05/11] perf/uprobe: Simplify UPROBE_HANDLER_REMOVE logic Peter Zijlstra
2024-07-11 11:02 ` [PATCH v2 06/11] perf/uprobe: SRCU-ify uprobe->consumer list Peter Zijlstra
2024-07-12 21:06   ` Andrii Nakryiko
2024-07-15 11:25     ` Peter Zijlstra
2024-07-15 17:30       ` Andrii Nakryiko
2024-07-11 11:02 ` [PATCH v2 07/11] perf/uprobe: Split uprobe_unregister() Peter Zijlstra
2024-07-12 21:10   ` Andrii Nakryiko
2024-07-11 11:02 ` [PATCH v2 08/11] perf/uprobe: Convert (some) uprobe->refcount to SRCU Peter Zijlstra
2024-07-11 14:03   ` Jiri Olsa
2024-07-12 21:21   ` Andrii Nakryiko
2024-07-11 11:02 ` [PATCH v2 09/11] srcu: Add __srcu_clone_read_lock() Peter Zijlstra
2024-07-11 11:02 ` [PATCH v2 10/11] perf/uprobe: Convert single-step and uretprobe to SRCU Peter Zijlstra
2024-07-11 16:06   ` Oleg Nesterov
2024-07-11 18:42     ` Peter Zijlstra
2024-07-12 10:26       ` Oleg Nesterov
2024-07-12 21:28   ` Andrii Nakryiko
2024-07-15 11:59     ` Peter Zijlstra
2024-07-11 11:02 ` [PATCH v2 11/11] perf/uprobe: Add uretprobe timer Peter Zijlstra
2024-07-11 13:19   ` Oleg Nesterov
2024-07-11 15:00     ` Peter Zijlstra
2024-07-11 15:55       ` Peter Zijlstra
2024-07-11 16:06         ` Peter Zijlstra
2024-07-12 21:43   ` Andrii Nakryiko
2024-07-15 11:41     ` Peter Zijlstra
2024-07-15 17:34       ` Andrii Nakryiko
2024-07-12  4:57 ` [PATCH v2 00/11] perf/uprobe: Optimize uprobes Andrii Nakryiko
2024-07-12  9:13   ` Peter Zijlstra
2024-07-12 13:10   ` Peter Zijlstra
2024-07-12 15:29     ` Andrii Nakryiko
2024-07-15 14:45   ` Peter Zijlstra
2024-07-15 17:10     ` Andrii Nakryiko
2024-07-15 18:10       ` Andrii Nakryiko
2024-07-19 18:42         ` Andrii Nakryiko
2024-07-27  0:18           ` Andrii Nakryiko

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=20240715112135.GC14400@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=clm@meta.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=rostedt@goodmis.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.