All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: mingo@kernel.org, andrii@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	mhiramat@kernel.org, jolsa@kernel.org, clm@meta.com,
	paulmck@kernel.org
Subject: Re: [PATCH 04/10] perf/uprobe: RCU-ify find_uprobe()
Date: Mon, 8 Jul 2024 20:08:37 +0200	[thread overview]
Message-ID: <20240708180837.GC27299@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20240708163545.GB18761@redhat.com>

On Mon, Jul 08, 2024 at 06:35:45PM +0200, Oleg Nesterov wrote:
> I hate to say this again, but I'll try to read this series later ;)
> 
> But let me ask...

:-)

> On 07/08, Peter Zijlstra wrote:
> >
> > +static void uprobe_free_rcu(struct rcu_head *rcu)
> > +{
> > +	struct uprobe *uprobe = container_of(rcu, struct uprobe, rcu);
> > +	kfree(uprobe);
> > +}
> > +
> >  static void put_uprobe(struct uprobe *uprobe)
> >  {
> >  	if (refcount_dec_and_test(&uprobe->ref)) {
> > @@ -604,7 +612,7 @@ static void put_uprobe(struct uprobe *up
> >  		mutex_lock(&delayed_uprobe_lock);
> >  		delayed_uprobe_remove(uprobe, NULL);
> >  		mutex_unlock(&delayed_uprobe_lock);
> > -		kfree(uprobe);
> > +		call_rcu(&uprobe->rcu, uprobe_free_rcu);
> 
> kfree_rcu() ?

I can never remember how that works, also this will very soon be
call_srcu().

> >  static struct uprobe *find_uprobe(struct inode *inode, loff_t offset)
> >  {
> > -	struct uprobe *uprobe;
> > +	unsigned int seq;
> >
> > -	read_lock(&uprobes_treelock);
> > -	uprobe = __find_uprobe(inode, offset);
> > -	read_unlock(&uprobes_treelock);
> > +	guard(rcu)();
> >
> > -	return uprobe;
> > +	do {
> > +		seq = read_seqcount_begin(&uprobes_seqcount);
> > +		struct uprobe *uprobe = __find_uprobe(inode, offset);
> > +		if (uprobe) {
> > +			/*
> > +			 * Lockless RB-tree lookups are prone to false-negatives.
> > +			 * If they find something, it's good.
> 
> Is it true in this case?
> 
> Suppose we have uprobe U which has no extra refs, so uprobe_unregister()
> called by the task X should remove it from uprobes_tree and kfree.
> 
> Suppose that the task T hits the breakpoint and enters handle_swbp().
> 
> Now,
> 
> 	- X calls find_uprobe(), this increments U->ref from 1 to 2
> 
> 	  register_for_each_vma() succeeds
> 
> 	  X enters delete_uprobe()
> 
> 	- T calls find_active_uprobe() -> find_uprobe()
> 
> 	  __read_seqcount_begin__read_seqcount_begin() returns an even number
> 
> 	  __find_uprobe() -> rb_find_rcu() succeeds
> 
> 	- X continues and returns from delete_uprobe(), U->ref == 1
> 
> 	  then it does the final uprobe_unregister()->put_uprobe(U),
> 	  refcount_dec_and_test() succeeds, X calls call_rcu(uprobe_free_rcu).
> 
> 	- T does get_uprobe() which changes U->ref from 0 to 1, __find_uprobe()
> 	  returns, find_uprobe() doesn't check read_seqcount_retry().

I think you're right. However, this get_uprobe() will go away in a few
patches.

But yeah, I should perhaps have been more careful when splitting things
up :/

  reply	other threads:[~2024-07-08 18:08 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-08  9:12 [PATCH 00/10] perf/uprobe: Optimize uprobes Peter Zijlstra
2024-07-08  9:12 ` [PATCH 01/10] perf/uprobe: Re-indent labels Peter Zijlstra
2024-07-08  9:12 ` [PATCH 02/10] perf/uprobe: Remove spurious whitespace Peter Zijlstra
2024-07-08  9:12 ` [PATCH 03/10] rbtree: Provide rb_find_rcu() / rb_find_add_rcu() Peter Zijlstra
2024-07-10  1:29   ` Masami Hiramatsu
2024-07-10  7:55     ` Peter Zijlstra
2024-07-10 14:05       ` Masami Hiramatsu
2024-07-08  9:12 ` [PATCH 04/10] perf/uprobe: RCU-ify find_uprobe() Peter Zijlstra
2024-07-08 16:35   ` Oleg Nesterov
2024-07-08 18:08     ` Peter Zijlstra [this message]
2024-07-09 14:32       ` Oleg Nesterov
2024-07-09 15:02         ` Peter Zijlstra
2024-07-09 15:23           ` Oleg Nesterov
2024-07-08  9:12 ` [PATCH 05/10] perf/uprobe: SRCU-ify uprobe->consumer list Peter Zijlstra
2024-07-09 12:05   ` Peter Zijlstra
2024-07-09 13:33     ` Oleg Nesterov
2024-07-09 14:32       ` Peter Zijlstra
2024-07-09 15:05         ` Oleg Nesterov
2024-07-09 15:19           ` Peter Zijlstra
2024-07-09 15:34             ` Oleg Nesterov
2024-07-09 14:32       ` Peter Zijlstra
2024-07-08  9:12 ` [PATCH 06/10] perf/uprobe: Split uprobe_unregister() Peter Zijlstra
2024-07-10  1:40   ` Masami Hiramatsu
2024-07-08  9:12 ` [PATCH 07/10] perf/uprobe: Convert (some) uprobe->refcount to SRCU Peter Zijlstra
2024-07-08  9:12 ` [PATCH 08/10] srcu: Add __srcu_clone_read_lock() Peter Zijlstra
2024-07-10  5:48   ` Boqun Feng
2024-07-10 10:02     ` Peter Zijlstra
2024-07-10 12:05       ` Peter Zijlstra
2024-07-08  9:12 ` [PATCH 09/10] perf/uprobe: Convert single-step and uretprobe to SRCU Peter Zijlstra
2024-07-08  9:12 ` [PATCH 10/10] perf/uprobe: Add uretprobe timer Peter Zijlstra
2024-07-08 22:56 ` [PATCH 00/10] perf/uprobe: Optimize uprobes Masami Hiramatsu
2024-07-09  0:25   ` Andrii Nakryiko
2024-07-09  9:01     ` Peter Zijlstra
2024-07-09 14:11       ` Paul E. McKenney
2024-07-09 14:29         ` Peter Zijlstra
2024-07-09 14:36           ` Paul E. McKenney
2024-07-09 15:31             ` Peter Zijlstra
2024-07-09 15:56               ` Paul E. McKenney
2024-07-09 16:10           ` Matthew Wilcox
2024-07-09 16:30             ` Matthew Wilcox
2024-07-09 16:57               ` Paul E. McKenney
2024-07-10  9:16             ` Peter Zijlstra
2024-07-10  9:40               ` Peter Zijlstra
2024-07-22 19:09                 ` Suren Baghdasaryan
2024-07-27  0:20                   ` Andrii Nakryiko
2024-07-27  1:29                     ` Suren Baghdasaryan
2024-07-27  3:45                       ` Matthew Wilcox
2024-07-30  3:18                         ` Andrii Nakryiko
2024-07-30 13:10                         ` Peter Zijlstra
2024-07-30 18:10                           ` Suren Baghdasaryan
2024-08-03  5:47                             ` Andrii Nakryiko
2024-08-03  8:53                               ` Peter Zijlstra
2024-08-04 23:22                                 ` Andrii Nakryiko
2024-08-06  4:08                                   ` Andrii Nakryiko
2024-08-06 14:50                                     ` Suren Baghdasaryan
2024-08-06 17:40                                       ` Andrii Nakryiko
2024-08-06 17:44                                         ` Suren Baghdasaryan
2024-08-07  1:36                                     ` Suren Baghdasaryan
2024-08-07  5:13                                       ` Suren Baghdasaryan
2024-08-07 17:49                                         ` Andrii Nakryiko
2024-08-07 18:04                                           ` Suren Baghdasaryan
2024-08-07 18:30                                             ` Andrii Nakryiko
2024-08-07 18:33                                             ` Suren Baghdasaryan
2024-08-08  0:47                                               ` Andrii Nakryiko
2024-07-30 13:46                   ` Peter Zijlstra
2024-07-30 18:16                     ` Suren Baghdasaryan
2024-07-09 16:42         ` Andrii Nakryiko
2024-07-09  9:03     ` Peter Zijlstra
2024-07-09 10:01       ` Jiri Olsa
2024-07-09 10:16         ` Peter Zijlstra
2024-07-09 22:10           ` Masami Hiramatsu
2024-07-10 10:10             ` Peter Zijlstra
2024-07-10 14:56               ` Masami Hiramatsu
2024-07-10 18:40                 ` Andrii Nakryiko
2024-07-11  8:51                   ` Peter Zijlstra
2024-07-11 15:17                     ` Masami Hiramatsu
2024-07-11 15:22                       ` Peter Zijlstra
2024-07-11 17:47                         ` Steven Rostedt
2024-07-11 23:59                           ` Masami Hiramatsu
2024-07-10  0:55       ` Masami Hiramatsu
2024-07-09 21:47     ` Andrii Nakryiko
2024-07-10 10:12       ` Peter Zijlstra
2024-07-10 12:34         ` Peter Zijlstra
2024-07-09  7:11   ` 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=20240708180837.GC27299@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=andrii@kernel.org \
    --cc=clm@meta.com \
    --cc=jolsa@kernel.org \
    --cc=linux-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.