linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	syzbot+721aa903751db87aa244@syzkaller.appspotmail.com,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Ingo Molnar <mingo@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	netdev <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH] tracepoint: Add tracepoint_probe_register_may_exist() for BPF tracing
Date: Wed, 7 Jul 2021 15:12:28 -0700	[thread overview]
Message-ID: <CAEf4BzZPb=cPf9V1Bz+USiq+b5opUTNkj4+CRjXdHcmExW3jVg@mail.gmail.com> (raw)
In-Reply-To: <20210629095543.391ac606@oasis.local.home>

On Tue, Jun 29, 2021 at 6:55 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
>
> All internal use cases for tracepoint_probe_register() is set to not ever
> be called with the same function and data. If it is, it is considered a
> bug, as that means the accounting of handling tracepoints is corrupted.
> If the function and data for a tracepoint is already registered when
> tracepoint_probe_register() is called, it will call WARN_ON_ONCE() and
> return with EEXISTS.
>
> The BPF system call can end up calling tracepoint_probe_register() with
> the same data, which now means that this can trigger the warning because
> of a user space process. As WARN_ON_ONCE() should not be called because
> user space called a system call with bad data, there needs to be a way to
> register a tracepoint without triggering a warning.
>
> Enter tracepoint_probe_register_may_exist(), which can be called, but will
> not cause a WARN_ON() if the probe already exists. It will still error out
> with EEXIST, which will then be sent to the user space that performed the
> BPF system call.
>
> This keeps the previous testing for issues with other users of the
> tracepoint code, while letting BPF call it with duplicated data and not
> warn about it.

There doesn't seem to be anything conceptually wrong with attaching
the same BPF program twice to the same tracepoint. Is it a hard
requirement to have a unique tp+callback combination, or was it done
mostly to detect an API misuse? How hard is it to support such use
cases?

I was surprised to discover this is not supported (though I never had
a use for this, had to construct a test to see the warning).

>
> Link: https://lore.kernel.org/lkml/20210626135845.4080-1-penguin-kernel@I-love.SAKURA.ne.jp/
> Link: https://syzkaller.appspot.com/bug?id=41f4318cf01762389f4d1c1c459da4f542fe5153 [1]`
>
> Cc: stable@vger.kernel.org
> Fixes: c4f6699dfcb85 ("bpf: introduce BPF_RAW_TRACEPOINT")
> Reported-by: syzbot <syzbot+721aa903751db87aa244@syzkaller.appspotmail.com>
> Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
>
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
>  include/linux/tracepoint.h | 10 ++++++++++
>  kernel/trace/bpf_trace.c   |  3 ++-
>  kernel/tracepoint.c        | 33 ++++++++++++++++++++++++++++++---
>  3 files changed, 42 insertions(+), 4 deletions(-)
>

[...]

  parent reply	other threads:[~2021-07-07 22:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 13:55 [PATCH] tracepoint: Add tracepoint_probe_register_may_exist() for BPF tracing Steven Rostedt
2021-06-29 14:16 ` [syzbot] WARNING in tracepoint_add_func syzbot
2021-07-07 22:12 ` Andrii Nakryiko [this message]
2021-07-07 22:45   ` [PATCH] tracepoint: Add tracepoint_probe_register_may_exist() for BPF tracing Steven Rostedt
2021-07-07 23:49     ` Andrii Nakryiko
2021-07-08  0:05       ` Steven Rostedt
2021-07-08  0:23         ` Andrii Nakryiko
2021-07-08  0:43           ` Steven Rostedt
2021-07-08 20:04             ` Andrii Nakryiko
2021-07-08 17:30           ` Mathieu Desnoyers
2021-07-08 20:11             ` 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='CAEf4BzZPb=cPf9V1Bz+USiq+b5opUTNkj4+CRjXdHcmExW3jVg@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=rostedt@goodmis.org \
    --cc=syzbot+721aa903751db87aa244@syzkaller.appspotmail.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).