From: Oleg Nesterov <oleg@redhat.com>
To: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, Martin KaFai Lau <kafai@fb.com>,
Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@chromium.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [RFC bpf-next 01/10] uprobe: Add session callbacks to uprobe_consumer
Date: Wed, 5 Jun 2024 18:36:25 +0200 [thread overview]
Message-ID: <20240605163624.GG25006@redhat.com> (raw)
In-Reply-To: <20240605160117.GE25006@redhat.com>
On 06/05, Oleg Nesterov wrote:
>
> On 06/05, Oleg Nesterov wrote:
> >
> > > +/*
> > > + * Make sure all the uprobe consumers have only one type of entry
> > > + * callback registered (either handler or handler_session) due to
> > > + * different return value actions.
> > > + */
> > > +static int consumer_check(struct uprobe_consumer *curr, struct uprobe_consumer *uc)
> > > +{
> > > + if (!curr)
> > > + return 0;
> > > + if (curr->handler_session || uc->handler_session)
> > > + return -EBUSY;
> > > + return 0;
> > > +}
> >
> > Hmm, I don't understand this code, it doesn't match the comment...
> >
> > The comment says "all the uprobe consumers have only one type" but
> > consumer_check() will always fail if the the 1st or 2nd consumer has
> > ->handler_session != NULL ?
> >
> > Perhaps you meant
> >
> > if (!!curr->handler != !!uc->handler)
> > return -EBUSY;
> >
> > ?
>
> OK, the changelog says
>
> Which means that there can be only single user of a uprobe (inode +
> offset) when session consumer is registered to it.
>
> so the code is correct. But I still think the comment is misleading.
Cough... perhaps it is correct but I am still confused even we forget about
the comment ;)
OK, uprobe can have a single consumer with ->handler_session != NULL. I guess
this is because return_instance->data is "global".
So uprobe can have multiple handler_session == NULL consumers before
handler_session != NULL, but not after ?
Oleg.
next prev parent reply other threads:[~2024-06-05 16:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-04 20:02 [RFC bpf-next 00/10] uprobe, bpf: Add session support Jiri Olsa
2024-06-04 20:02 ` [RFC bpf-next 01/10] uprobe: Add session callbacks to uprobe_consumer Jiri Olsa
2024-06-05 15:24 ` Oleg Nesterov
2024-06-05 16:01 ` Oleg Nesterov
2024-06-05 16:36 ` Oleg Nesterov [this message]
2024-06-05 20:18 ` Jiri Olsa
2024-06-05 17:25 ` Andrii Nakryiko
2024-06-05 17:56 ` Oleg Nesterov
2024-06-05 20:47 ` Andrii Nakryiko
2024-06-05 21:17 ` Jiri Olsa
2024-06-05 21:23 ` Oleg Nesterov
2024-06-05 20:50 ` Jiri Olsa
2024-06-05 21:00 ` Oleg Nesterov
2024-06-06 16:46 ` Jiri Olsa
2024-06-06 16:52 ` Andrii Nakryiko
2024-06-10 11:06 ` Jiri Olsa
2024-06-17 22:53 ` Andrii Nakryiko
2024-06-19 18:48 ` Jiri Olsa
2024-06-05 21:01 ` Jiri Olsa
2024-06-04 20:02 ` [RFC bpf-next 02/10] bpf: Add support for uprobe multi session attach Jiri Olsa
2024-06-04 20:02 ` [RFC bpf-next 03/10] bpf: Add support for uprobe multi session context Jiri Olsa
2024-06-04 20:02 ` [RFC bpf-next 04/10] libbpf: Add support for uprobe multi session attach Jiri Olsa
2024-06-04 20:02 ` [RFC bpf-next 05/10] libbpf: Add uprobe session attach type names to attach_type_name Jiri Olsa
2024-06-04 20:02 ` [RFC bpf-next 06/10] selftests/bpf: Move ARRAY_SIZE to bpf_misc.h Jiri Olsa
2024-06-04 20:02 ` [RFC bpf-next 07/10] selftests/bpf: Add uprobe session test Jiri Olsa
2024-06-04 20:02 ` [RFC bpf-next 08/10] selftests/bpf: Add uprobe session errors test Jiri Olsa
2024-06-04 20:02 ` [RFC bpf-next 09/10] selftests/bpf: Add uprobe session cookie test Jiri Olsa
2024-06-04 20:02 ` [RFC bpf-next 10/10] selftests/bpf: Add uprobe session recursive test Jiri Olsa
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=20240605163624.GG25006@redhat.com \
--to=oleg@redhat.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.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 \
--cc=sdf@google.com \
--cc=songliubraving@fb.com \
--cc=yhs@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).