From: Steven Rostedt <rostedt@goodmis.org>
To: Ming Lei <ming.lei@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Ming Lei <tom.leiming@gmail.com>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
linux-block <linux-block@vger.kernel.org>
Subject: Re: kprobe: __blkdev_put probe is missed
Date: Mon, 22 Jun 2020 09:01:48 -0400 [thread overview]
Message-ID: <20200622090148.6e0f2ac9@oasis.local.home> (raw)
In-Reply-To: <20200622002753.GC670933@T590>
On Mon, 22 Jun 2020 08:27:53 +0800
Ming Lei <ming.lei@redhat.com> wrote:
> Can you kprobe guys improve the implementation for covering this case?
> For example, put probe on 3) in case the above situation is recognized.
To do so would require solving the halting problem.
https://en.wikipedia.org/wiki/Halting_problem
Or perhaps reading the DWARF output of the compiler to determine if it
optimized the location you are looking for.
The first case is impossible to solve, the second would take a lot of
work, (are you going to fund it?)
Your comment about tracing internals is valid, but if you can't
understand the optimization of the compiler on the kernel, I suggest
you stick with the static trace events. kprobes can be added virtual
anywhere in the kernel. It's very function requires a kprobe *user* to
understand the internals of the kernel as well as its executable binary
code, and not expect the kprobe to figure it out for you.
We are all for adding infrastructure to make kprobes easier. But
figuring out that the kernel optimized a function call so that we can
add some wrapper to *simulate* the optimized out function call is
something I believe is out of scope for a kprobe. In fact, I would call
that a feature! I would like to know that a function was optimized out.
When I add a kprobe, I'm more interested in what the compiler actually
did to the kernel than what the source code shows us. That is very
useful information.
-- Steve
next prev parent reply other threads:[~2020-06-22 13:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-17 10:30 krobe: " Ming Lei
2020-06-18 12:54 ` kprobe: " Ming Lei
2020-06-18 13:56 ` Masami Hiramatsu
2020-06-18 23:19 ` Ming Lei
2020-06-19 5:12 ` Masami Hiramatsu
2020-06-19 7:28 ` Ming Lei
2020-06-19 12:19 ` Steven Rostedt
2020-06-19 13:32 ` Ming Lei
2020-06-19 15:35 ` Masami Hiramatsu
2020-06-19 23:28 ` Ming Lei
2020-06-20 0:59 ` Steven Rostedt
2020-06-20 1:37 ` Masami Hiramatsu
2020-06-22 0:27 ` Ming Lei
2020-06-22 1:34 ` Masami Hiramatsu
2020-06-22 13:01 ` Steven Rostedt [this message]
2020-06-22 23:47 ` Masami Hiramatsu
2020-06-23 0:38 ` Masami Hiramatsu
2020-06-23 5:28 ` 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=20200622090148.6e0f2ac9@oasis.local.home \
--to=rostedt@goodmis.org \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=ming.lei@redhat.com \
--cc=naveen.n.rao@linux.ibm.com \
--cc=tom.leiming@gmail.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
all inboxes | Powered by JetHome®