All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Peter Zijlstra <peterz@infradead.org>,
	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: Sat, 26 Jun 2021 19:35:40 -0400	[thread overview]
Message-ID: <20210626193540.706da950@rorschach.local.home> (raw)
In-Reply-To: <1252314758.18555.1624732969232.JavaMail.zimbra@efficios.com>

On Sat, 26 Jun 2021 14:42:49 -0400 (EDT)
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> > If BPF is OK with registering the same probe more than once if user
> > space expects it, we can add this patch, which allows the caller (in
> > this case BPF) to not warn if the probe being registered is already
> > registered, and keeps the idea that a probe registered twice is a bug
> > for all other use cases.  
> 
> How can removal of the duplicates be non buggy then ? The first removal will match both probes.

The registering of the first duplicate would fail with an error, but
will not warn. There would be no unregistering needed.

-- Steve

  reply	other threads:[~2021-06-26 23:35 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
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 [this message]
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=20210626193540.706da950@rorschach.local.home \
    --to=rostedt@goodmis.org \
    --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=penguin-kernel@i-love.sakura.ne.jp \
    --cc=peterz@infradead.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.