linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: rostedt@goodmis.org (Steven Rostedt)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 00/11] Early kprobe: enable kprobes at very early
Date: Fri, 16 Jan 2015 12:48:11 -0500	[thread overview]
Message-ID: <20150116174811.GA7817@home.goodmis.org> (raw)
In-Reply-To: <1420616086-42692-1-git-send-email-wangnan0@huawei.com>

On Wed, Jan 07, 2015 at 03:34:46PM +0800, Wang Nan wrote:
> 
> Patch 10 enables cmdline option 'ekprobe=', allows setup probe at
> cmdline. However, currently the kprobe handler is only a simple printk.
> 
> Patch 11 introduces required Kconfig options to actually enable early
> kprobes.
> 
> Usage of early kprobe is as follow:
> 
> Booting kernel with cmdline 'ekprobe=', like:
> 
> ... rdinit=/sbin/init ekprobe=0xc00f3c2c ekprobe=__free_pages ...

Perhaps you should specify what the probe will do. For now it is only printk.
For example:

  ekprobe=printk,__free_pages

That is, here you are attaching a printk to __free_pages.

Later, when you implement tracing, you could have:

 ekprobe=trace,__free_pages

where it will be sent to the ring buffer.

This will maintain backward compatibility when you add new features. Instead
of getting something like printk working now, and people use it for such,
and then when you switch it over to tracing, it breaks the printk version.

Also, if you plan on converting early kprobes to normal kprobes during boot,
then it should just be kprobes=..., why add the 'e'. It being early is just
an implementation detail, not something that should be expressed by the users
of the facility.

-- Steve


> 
> During boot, kernel will print trace using printk:
> 
>  ...
>  Hit early kprobe at __alloc_pages_nodemask+0x4
>  Hit early kprobe at __free_pages+0x0
>  Hit early kprobe at __alloc_pages_nodemask+0x4
>  Hit early kprobe at __free_pages+0x0
>  Hit early kprobe at __free_pages+0x0
>  Hit early kprobe at __alloc_pages_nodemask+0x4
>  ...

      parent reply	other threads:[~2015-01-16 17:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-07  7:34 [RFC PATCH 00/11] Early kprobe: enable kprobes at very early Wang Nan
2015-01-07  7:35 ` [RFC PATCH 01/11] ARM: kprobes: directly modify code if kprobe is not initialized Wang Nan
2015-01-07 17:15   ` Christopher Covington
2015-01-13 15:34   ` Masami Hiramatsu
2015-01-07  7:35 ` [RFC PATCH 02/11] ARM: kprobes: introduce early kprobes related code area Wang Nan
2015-01-07  7:35 ` [RFC PATCH 03/11] x86: kprobes: directly modify code if kprobe is not initialized Wang Nan
2015-01-07  7:35 ` [RFC PATCH 04/11] x86: kprobes: introduce early kprobes related code area Wang Nan
2015-01-07  7:35 ` [RFC PATCH 05/11] kprobes: Add an KPROBE_FLAG_EARLY for early kprobe Wang Nan
2015-01-07  7:35 ` [RFC PATCH 06/11] kprobes: makes kprobes_initialized globally visable Wang Nan
2015-01-07  7:35 ` [RFC PATCH 07/11] kprobes: introduces macros for allocing early kprobe resources Wang Nan
2015-01-07 10:45   ` Wang Nan
2015-01-07  7:35 ` [RFC PATCH 08/11] kprobes: allows __alloc_insn_slot() from early kprobes slots Wang Nan
2015-01-07  7:36 ` [RFC PATCH 09/11] kprobes: core logic of eraly kprobes Wang Nan
2015-01-07  7:36 ` [RFC PATCH 10/11] kprobes: enable 'ekprobe=' cmdline option for early kprobes Wang Nan
2015-01-07  7:36 ` [RFC PATCH 11/11] kprobes: add CONFIG_EARLY_KPROBES option Wang Nan
2015-01-07  7:42 ` Wang Nan
2015-01-13 15:58 ` [RFC PATCH 00/11] Early kprobe: enable kprobes at very early Masami Hiramatsu
2015-02-06 10:30   ` [RFC PATCH] x86: kprobes: enable optmize relative call insn Wang Nan
2015-02-07 10:08     ` Masami Hiramatsu
2015-02-07 10:42       ` Wang Nan
2015-01-16 17:48 ` Steven Rostedt [this message]

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=20150116174811.GA7817@home.goodmis.org \
    --to=rostedt@goodmis.org \
    --cc=linux-arm-kernel@lists.infradead.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).