From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] kprobes: Print an error if probe is rejected
Date: Fri, 11 Jun 2021 19:25:38 +0530 [thread overview]
Message-ID: <1623419180.o4u5xf72jm.naveen@linux.ibm.com> (raw)
In-Reply-To: <20210610191643.d24e7d56d102567070fe8386@kernel.org>
Hi Masami,
Thanks for the review.
Masami Hiramatsu wrote:
> Hi Naveen,
>
> On Thu, 10 Jun 2021 14:26:17 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>
>> When probing at different locations in the kernel, it is not always
>> evident if the location can be probed or not. As an example:
>>
>> $ perf probe __radix__flush_tlb_range:35
>> Failed to write event: Invalid argument
>> Error: Failed to add events.
>>
>> The probed line above is:
>> 35 if (!mmu_has_feature(MMU_FTR_GTSE) && type == FLUSH_TYPE_GLOBAL) {
>>
>> This ends up trying to probe on BUILD_BUG_ON(), which is rejected.
>> However, the user receives no indication at all as to why the probe
>> failed. Print an error in such cases so that it is clear that the probe
>> was rejected.
>
> Hmm, Nack for this way, but I understand that is a problem.
> If you got the error in perf probe, which uses ftrace dynamic-event interface.
> In that case, the errors should not be output in the dmesg, but are reported
> via error_log in tracefs.
That would be a nice thing to add to perf, but I don't see why this
should be a either/or. I still think it is good to have the core kprobe
infrastructure print such errors in the kernel log. It is easier to look
up such error strings in the kernel source to understand why a probe was
rejected.
We also have perf_event_open() as an interface to add probes, and I
don't think it would be helpful to require all tools to utilize the
error log from tracefs for this purpose.
- Naveen
next prev parent reply other threads:[~2021-06-11 13:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 8:56 [PATCH] kprobes: Print an error if probe is rejected Naveen N. Rao
2021-06-10 10:16 ` Masami Hiramatsu
2021-06-10 17:33 ` Steven Rostedt
2021-06-11 1:50 ` Masami Hiramatsu
2021-06-11 13:55 ` Naveen N. Rao [this message]
2021-06-11 19:40 ` Steven Rostedt
2021-06-14 15:30 ` Naveen N. Rao
2021-06-18 16:15 ` Masami Hiramatsu
2021-06-21 9:36 ` Naveen N. Rao
2021-06-21 12:54 ` Masami Hiramatsu
2021-06-12 1:13 ` Masami Hiramatsu
2021-06-14 15:37 ` Naveen N. Rao
2021-06-15 5:42 ` Masami Hiramatsu
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=1623419180.o4u5xf72jm.naveen@linux.ibm.com \
--to=naveen.n.rao@linux.vnet.ibm.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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 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).