From: Oleg Nesterov <oleg@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: andrii@kernel.org, mhiramat@kernel.org, peterz@infradead.org,
jolsa@kernel.org, rostedt@goodmis.org,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] uprobes: shift put_uprobe() from delete_uprobe() to uprobe_unregister()
Date: Tue, 30 Jul 2024 19:17:34 +0200 [thread overview]
Message-ID: <20240730171733.GA10822@redhat.com> (raw)
In-Reply-To: <CAEf4BzZ=vMh9=t3iH+pqwTDaYGfXvuF-0BqaLsOgAx2qV7Vqzw@mail.gmail.com>
Thanks for looking at this!
On 07/30, Andrii Nakryiko wrote:
>
> BTW, do you have anything against me changing refcounting so that
> uprobes_tree itself doesn't hold a refcount, and all the refcounting
> is done based on consumers holding implicit refcount and whatever
> temporary get/put uprobe is necessary for runtime uprobe/uretprobe
> functioning.
No, I have nothing against.
To be honest, I don't really understand the value of this change, but
a) this is probably because I didn't see a separate patch(es) which
does this and b) assuming that it doesn't complicate the code too much
I won't argue in any case ;)
And in fact I had your proposed change in mind when I did these cleanups.
I think that they can even simplify this change, at least I hope they can
not complicate it.
> BTW, do you plan
> any more clean ups like this? It's a bit of a moving target because of
> your refactoring, so I'd appreciate some stability to build upon :)
Well yes... may be this week.
I'd like to (try to) optimize/de-uglify register_for_each_vma() for
the multiple-consumers case. And, more importantly, the case when perf
does uprobe_register() + uprobe_apply().
But. All these changes will only touch the register_for_each_vma() paths,
so this is completely orthogonal to this series and your and/or Peter's
changes.
> Also, can you please push this and your previous patch set into some
> branch somewhere I can pull from, preferably based on the latest
> linux-trace's probes/for-next? Thanks!
Cough ;)
No, sorry, I can't. I lost my kernel.org account years ago (and this is
the second time this has happened!), but since I am a lazy dog I didn't
even bother to try to restore it.
> Acked-by: Andrii Nakryiko <andrii@kernel.org>
Thanks!
> > @@ -1102,10 +1100,16 @@ void uprobe_unregister(struct uprobe *uprobe, struct uprobe_consumer *uc)
> > err = register_for_each_vma(uprobe, NULL);
> >
> > /* TODO : cant unregister? schedule a worker thread */
> > - if (!err && !uprobe->consumers)
> > - delete_uprobe(uprobe);
> > + if (!err) {
> > + if (!uprobe->consumers)
> > + delete_uprobe(uprobe);
> > + else
> > + err = -EBUSY;
>
> This bit is weird because really it's not an error... but this makes
> this change simpler and moves put_uprobe outside of rwsem.
Agreed, uprobe->consumers != NULL is not an error. But we don't return
this error code, just we need to ensure that "err == 0" means that
"delete_uprobe() was actually called".
> With my
> proposed change to refcounting schema this would be unnecessary,
Yes.
Oleg.
next prev parent reply other threads:[~2024-07-30 17:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-30 12:34 [PATCH 0/3] uprobes: simplify _unregister paths Oleg Nesterov
2024-07-30 12:34 ` [PATCH 1/3] uprobes: change uprobe_register() to use uprobe_unregister() instead of __uprobe_unregister() Oleg Nesterov
2024-07-30 15:00 ` Andrii Nakryiko
2024-07-30 12:34 ` [PATCH 2/3] uprobes: fold __uprobe_unregister() into uprobe_unregister() Oleg Nesterov
2024-07-30 15:01 ` Andrii Nakryiko
2024-07-30 12:34 ` [PATCH 3/3] uprobes: shift put_uprobe() from delete_uprobe() to uprobe_unregister() Oleg Nesterov
2024-07-30 15:08 ` Andrii Nakryiko
2024-07-30 17:17 ` Oleg Nesterov [this message]
2024-07-30 17:27 ` Andrii Nakryiko
2024-07-30 20:55 ` Peter Zijlstra
2024-07-30 21:58 ` Andrii Nakryiko
2024-07-30 15:10 ` [PATCH 0/3] uprobes: simplify _unregister paths Andrii Nakryiko
2024-07-30 20:20 ` Jiri Olsa
2024-07-31 9:46 ` Masami Hiramatsu
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=20240730171733.GA10822@redhat.com \
--to=oleg@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=peterz@infradead.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.