All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
	"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
	"David S . Miller" <davem@davemloft.net>,
	Ian McDonald <ian.mcdonald@jandi.co.nz>,
	Vlad Yasevich <vyasevich@gmail.com>,
	Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs
Date: Thu, 5 Oct 2017 16:35:22 -0700	[thread overview]
Message-ID: <CAGXu5jJbSFjck+_-RGQytkDuRhtc1U=pYXavyxpbjd_W-=N_tA@mail.gmail.com> (raw)
In-Reply-To: <150724519527.5014.10207042218696587159.stgit@devbox>

On Thu, Oct 5, 2017 at 4:13 PM, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Hi,
>
> This series abolishes jprobe APIs and remove or disable related
> code. This is a preparation of removing all jprobe code (including
> kprobe's break_handler.)
> I'm not so sure how many jprobe users still exists, but
> please migrate your tool to trace-event or perf-probe.
>
> As we discussed this thread ( https://lkml.org/lkml/2017/10/2/386 ),
> we decided to remove jprobe.
>
> Nowadays ftrace and other tracing features are enough matured
> to replace jprobe use-cases. Users can safely use ftrace and
> perf probe etc. for their use cases. So we have better way.
> IOW, jprobe finished its task.
>
> People who still use jprobe, must migrate to other tracing features.
> Please consider to migrate your tool to following options.
>
> - Use trace-event to trace target function with arguments
>   trace-event is a low-overhead (and almost no visible overhead if it
>   is off) statically defined event interface. You can define new events
>   and trace it via ftrace or any other tracing tools.
>   See following urls,
>   - https://lwn.net/Articles/379903/
>   - https://lwn.net/Articles/381064/
>   - https://lwn.net/Articles/383362/

It seems this method requires setting up the target trace ahead of time?

> - Use ftrace dynamic events (kprobe event) with perf-probe
>   If you build your kernel with debug info (CONFIG_DEBUG_INFO), you can
>   find which register/stack is assigned to which local variable or arguments
>   by using perf-probe and set up new event to trace it.
>   See following documents,
>   - Documentation/trace/kprobetrace.txt
>   - Documentation/trace/events.txt
>   - tools/perf/Documentation/perf-probe.txt

These seem to be more about setting up probes from userspace.

> As far as I can see, tcp probe, dccp probe, sctp probe and lkdtm
> are using jprobe to probe function. Please consider to migrate.

I'm happy to do so, but I'm quite unfamiliar with how to do this (I
didn't write lkdtm's jprobe code originally). lkdtm just wants to hook
function entry and call it's own function before.

It uses struct jprobe like this:

                .jprobe = {                                     \
                        .kp.symbol_name = _symbol,              \
                        .entry = (kprobe_opcode_t *)_entry,     \
                },                                              \

and defines a bunch of handlers like this for the _symbol and _entry pairs:

                   "do_IRQ",                    jp_do_irq),
...
                   "tasklet_action",            jp_tasklet_action),

where all the handlers look exactly the same (and don't care about arguments):

static unsigned int jp_do_irq(unsigned int irq)
{
        lkdtm_handler();
        jprobe_return();
        return 0;
}

What's the right way to migrate away from jprobe for lkdtm?

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

  parent reply	other threads:[~2017-10-05 23:35 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-05 23:13 [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs Masami Hiramatsu
2017-10-05 23:13 ` [RFC PATCH -tip 1/5] kprobes: Use ENOTSUPP instead of ENOSYS Masami Hiramatsu
2017-10-20  8:57   ` Ingo Molnar
2017-10-20 15:51     ` Masami Hiramatsu
2017-10-05 23:14 ` [RFC PATCH -tip 2/5] kprobes: Abolish jprobe APIs Masami Hiramatsu
2017-10-20 12:26   ` [tip:perf/core] kprobes: Disable the jprobes APIs tip-bot for Masami Hiramatsu
2017-10-05 23:15 ` [RFC PATCH -tip 3/5] kprobes: Disable jprobe test code Masami Hiramatsu
2017-10-20 12:26   ` [tip:perf/core] kprobes: Disable the jprobes " tip-bot for Masami Hiramatsu
2017-10-05 23:15 ` [RFC PATCH -tip 4/5] kprobes: Remove jprobe sample code Masami Hiramatsu
2017-10-20 12:27   ` [tip:perf/core] kprobes: Remove the jprobes " tip-bot for Masami Hiramatsu
2017-10-05 23:16 ` [RFC PATCH -tip 5/5] kprobes: docs: Remove jprobe related document Masami Hiramatsu
2017-10-20 12:27   ` [tip:perf/core] kprobes/docs: Remove jprobes related documents tip-bot for Masami Hiramatsu
2017-10-05 23:35 ` Kees Cook [this message]
2017-10-05 23:58   ` [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs Steven Rostedt
2017-10-06  0:06     ` Kees Cook
2017-10-06  4:49     ` Masami Hiramatsu
2017-10-06 12:58       ` Steven Rostedt
2017-10-06 15:34       ` Steven Rostedt
2017-10-07  5:24         ` Stafford Horne
2017-10-09 16:48           ` Steven Rostedt
2017-10-07  8:55         ` Ingo Molnar
2017-10-09 16:45           ` Steven Rostedt
2017-10-07  9:35         ` Masami Hiramatsu
2017-10-09 16:59           ` Steven Rostedt
2017-10-09 15:33         ` Jonathan Corbet
2017-10-09 16:20           ` Steven Rostedt
2017-10-09 16:33             ` Jonathan Corbet
2017-10-09 16:41               ` Steven Rostedt
2017-10-09 18:10           ` Steven Rostedt
2017-10-10 14:02           ` Steven Rostedt
2017-10-06  0:32   ` Masami Hiramatsu
2017-10-06  1:11     ` Steven Rostedt
2017-10-06  4:47       ` Masami Hiramatsu
2017-10-20 12:22 ` Ingo Molnar
2017-10-20 13:32   ` Kees Cook
2017-10-20 15:17     ` Ingo Molnar
2017-10-20 16:28       ` Kees Cook
2017-10-21  8:06         ` Greg Kroah-Hartman

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='CAGXu5jJbSFjck+_-RGQytkDuRhtc1U=pYXavyxpbjd_W-=N_tA@mail.gmail.com' \
    --to=keescook@chromium.org \
    --cc=ananth@linux.vnet.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=ast@kernel.org \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=ian.mcdonald@jandi.co.nz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=stephen@networkplumber.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vyasevich@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 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.