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 17:24:57 +0200 [thread overview]
Message-ID: <20240605152457.GD25006@redhat.com> (raw)
In-Reply-To: <20240604200221.377848-2-jolsa@kernel.org>
I'll try to read this code tomorrow, right now I don't really understand
what does it do and why.
However,
On 06/04, Jiri Olsa wrote:
>
> struct uprobe_consumer {
> + /*
> + * The handler callback return value controls removal of the uprobe.
> + * 0 on success, uprobe stays
> + * 1 on failure, remove the uprobe
> + * console warning for anything else
> + */
> int (*handler)(struct uprobe_consumer *self, struct pt_regs *regs);
This is misleading. It is not about success/failure, it is about filtering.
consumer->handler() returns UPROBE_HANDLER_REMOVE if this consumer is not
interested in this task, so this uprobe can be removed (unless another
consumer returns 0).
> +/*
> + * 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;
?
Oleg.
next prev parent reply other threads:[~2024-06-05 15:26 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 [this message]
2024-06-05 16:01 ` Oleg Nesterov
2024-06-05 16:36 ` Oleg Nesterov
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=20240605152457.GD25006@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 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.