All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Ingo Molnar <mingo@kernel.org>, Robert Richter <rric@kernel.org>,
	Gabriel Krisman Bertazi <krisman@collabora.com>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	linux-kernel@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	netdev <netdev@vger.kernel.org>,
	bpf@vger.kernel.org
Subject: Re: [PATCH] tracepoint: Do not warn on EEXIST or ENOENT
Date: Sun, 27 Jun 2021 00:13:17 +0900	[thread overview]
Message-ID: <7297f336-70e5-82d3-f8d3-27f08c7d1548@i-love.sakura.ne.jp> (raw)
In-Reply-To: <20210626101834.55b4ecf1@rorschach.local.home>

On 2021/06/26 23:18, Steven Rostedt wrote:
> On Sat, 26 Jun 2021 22:58:45 +0900
> Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
> 
>> syzbot is hitting WARN_ON_ONCE() at tracepoint_add_func() [1], but
>> func_add() returning -EEXIST and func_remove() returning -ENOENT are
>> not kernel bugs that can justify crashing the system.
> 
> There should be no path that registers a tracepoint twice. That's a bug
> in the kernel. Looking at the link below, I see the backtrace:
> 
> Call Trace:
>  tracepoint_probe_register_prio kernel/tracepoint.c:369 [inline]
>  tracepoint_probe_register+0x9c/0xe0 kernel/tracepoint.c:389
>  __bpf_probe_register kernel/trace/bpf_trace.c:2154 [inline]
>  bpf_probe_register+0x15a/0x1c0 kernel/trace/bpf_trace.c:2159
>  bpf_raw_tracepoint_open+0x34a/0x720 kernel/bpf/syscall.c:2878
>  __do_sys_bpf+0x2586/0x4f40 kernel/bpf/syscall.c:4435
>  do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
> 
> So BPF is allowing the user to register the same tracepoint more than
> once? That looks to be a bug in the BPF code where it shouldn't be
> allowing user space to register the same tracepoint multiple times.

I didn't catch your question.

  (1) func_add() can reject an attempt to add same tracepoint multiple times
      by returning -EINVAL to the caller.
  (2) But tracepoint_add_func() (the caller of func_add()) is calling WARN_ON_ONCE()
      if func_add() returned -EINVAL.
  (3) And tracepoint_add_func() is triggerable via request from userspace.
  (4) tracepoint_probe_register_prio() serializes tracepoint_add_func() call
      triggered by concurrent request from userspace using tracepoints_mutex mutex.
  (5) But tracepoint_add_func() does not check whether same tracepoint multiple
      is already registered before calling func_add().
  (6) As a result, tracepoint_add_func() receives -EINVAL from func_add(), and
      calls WARN_ON_ONCE() and the system crashes due to panic_on_warn == 1.

Why this is a bug in the BPF code? The BPF code is not allowing userspace to
register the same tracepoint multiple times. I think that tracepoint_add_func()
is stupid enough to crash the kernel instead of rejecting when an attempt to
register the same tracepoint multiple times is made.


  reply	other threads:[~2021-06-26 15:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-26 13:58 [PATCH] tracepoint: Do not warn on EEXIST or ENOENT Tetsuo Handa
2021-06-26 14:18 ` Steven Rostedt
2021-06-26 15:13   ` Tetsuo Handa [this message]
2021-06-26 15:17     ` Tetsuo Handa
2021-06-26 15:41     ` Steven Rostedt
2021-06-26 18:22       ` Steven Rostedt
2021-06-26 18:42         ` Mathieu Desnoyers
2021-06-26 23:35           ` Steven Rostedt
2021-06-27  1:10         ` Tetsuo Handa
2021-06-27  2:52           ` Steven Rostedt

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=7297f336-70e5-82d3-f8d3-27f08c7d1548@i-love.sakura.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=gustavoars@kernel.org \
    --cc=krisman@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rric@kernel.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.