From: wangnan0@huawei.com (Wang Nan)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.
Date: Wed, 25 Feb 2015 19:46:49 +0800 [thread overview]
Message-ID: <54EDB629.4020908@huawei.com> (raw)
In-Reply-To: <54EDADD6.5070404@huawei.com>
On 2015/2/25 19:11, Wang Nan wrote:
> On 2015/2/20 11:59, Masami Hiramatsu wrote:
>> Hi,
>>
>> Sorry for replying late.
>>
>> (2015/02/13 14:39), Wang Nan wrote:
>>> I fell very sorry for people who reviewed my v2 patch series yesterday
>>> at https://lkml.org/lkml/2015/2/12/234 because I didn't provide enough
>>> information in commit log. This v3 patch series add those missing
>>> commit messages. There are also 2 small fix based on v2:
>>>
>>> 1. Fixes ftrace_sort_mcount_area. Original patch doesn't work for module.
>>> 2. Wraps setting of kprobes_initialized in stop_machine() context.
>>
>> From the viewpoint of the maintenance, it seems over-engineered and
>> not general implementation. Please reconsider just initializing breakpoint
>> handler in earlier stage. Since those exceptions may happen anywhere,
>> those trap handlers setup very early stage. E.g. on x86, setup_arch()
>> setup early_trap_init() at beginning. So we just need to initialize
>> kprobes earlier.
>
> I tried as your suggestion. For x86, int3 handler doesn't work correctly until
> trap_init(). I don't have enough time to look into this problem today (and I don't
> familiar with x86 architecture). Could you please have a look on it?
>
> Thank you.
>
Hi Masami,
Sorry for the noise. I have futher information may be useful.
I initialize kprobe and probed an instruction with int3 between setup_arch() and
trap_init(). It doesn't work at first. By dumping __log_buf[] I fount it reports NULL pointer panic.
With some random test I found following patch, which makes it works (looks like) correctly.
However I think there must be some reason to set dpl to '3' instead of '0' (set_mni_gate
use 0 as dpl). Do you have any suggestion on it?
Thank you.
------------- The patch ---------------
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 9d2073e..ac29277 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -925,9 +925,9 @@ dotraplinkage void do_iret_error(struct pt_regs *regs, long error_code)
/* Set of traps needed for early debugging. */
void __init early_trap_init(void)
{
- set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK);
+ set_intr_gate_ist(X86_TRAP_DB, &debug, 0);
/* int3 can be called from all */
- set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK);
+ set_intr_gate_ist(X86_TRAP_BP, &int3, 0);
#ifdef CONFIG_X86_32
set_intr_gate(X86_TRAP_PF, page_fault);
#endif
WARNING: multiple messages have this Message-ID (diff)
From: Wang Nan <wangnan0@huawei.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: <linux@arm.linux.org.uk>, <tglx@linutronix.de>,
<mingo@redhat.com>, <hpa@zytor.com>, <rostedt@goodmis.org>,
<ananth@in.ibm.com>, <anil.s.keshavamurthy@intel.com>,
<davem@davemloft.net>, <luto@amacapital.net>,
<keescook@chromium.org>, <oleg@redhat.com>,
<dave.long@linaro.org>, <tixy@linaro.org>, <nico@linaro.org>,
<yalin.wang2010@gmail.com>, <catalin.marinas@arm.com>,
<Yalin.Wang@sonymobile.com>, <mark.rutland@arm.com>,
<dave.hansen@linux.intel.com>, <jkenisto@us.ibm.com>,
<anton@samba.org>, <stefani@seibold.net>, <JBeulich@suse.com>,
<akpm@linux-foundation.org>, <rusty@rustcorp.com.au>,
<peterz@infradead.org>, <prarit@redhat.com>, <fabf@skynet.be>,
<hannes@cmpxchg.org>, <x86@kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <lizefan@huawei.com>,
"yrl.pp-manager.tt@hitachi.com" <yrl.pp-manager.tt@hitachi.com>
Subject: Re: [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.
Date: Wed, 25 Feb 2015 19:46:49 +0800 [thread overview]
Message-ID: <54EDB629.4020908@huawei.com> (raw)
In-Reply-To: <54EDADD6.5070404@huawei.com>
On 2015/2/25 19:11, Wang Nan wrote:
> On 2015/2/20 11:59, Masami Hiramatsu wrote:
>> Hi,
>>
>> Sorry for replying late.
>>
>> (2015/02/13 14:39), Wang Nan wrote:
>>> I fell very sorry for people who reviewed my v2 patch series yesterday
>>> at https://lkml.org/lkml/2015/2/12/234 because I didn't provide enough
>>> information in commit log. This v3 patch series add those missing
>>> commit messages. There are also 2 small fix based on v2:
>>>
>>> 1. Fixes ftrace_sort_mcount_area. Original patch doesn't work for module.
>>> 2. Wraps setting of kprobes_initialized in stop_machine() context.
>>
>> From the viewpoint of the maintenance, it seems over-engineered and
>> not general implementation. Please reconsider just initializing breakpoint
>> handler in earlier stage. Since those exceptions may happen anywhere,
>> those trap handlers setup very early stage. E.g. on x86, setup_arch()
>> setup early_trap_init() at beginning. So we just need to initialize
>> kprobes earlier.
>
> I tried as your suggestion. For x86, int3 handler doesn't work correctly until
> trap_init(). I don't have enough time to look into this problem today (and I don't
> familiar with x86 architecture). Could you please have a look on it?
>
> Thank you.
>
Hi Masami,
Sorry for the noise. I have futher information may be useful.
I initialize kprobe and probed an instruction with int3 between setup_arch() and
trap_init(). It doesn't work at first. By dumping __log_buf[] I fount it reports NULL pointer panic.
With some random test I found following patch, which makes it works (looks like) correctly.
However I think there must be some reason to set dpl to '3' instead of '0' (set_mni_gate
use 0 as dpl). Do you have any suggestion on it?
Thank you.
------------- The patch ---------------
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 9d2073e..ac29277 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -925,9 +925,9 @@ dotraplinkage void do_iret_error(struct pt_regs *regs, long error_code)
/* Set of traps needed for early debugging. */
void __init early_trap_init(void)
{
- set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK);
+ set_intr_gate_ist(X86_TRAP_DB, &debug, 0);
/* int3 can be called from all */
- set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK);
+ set_intr_gate_ist(X86_TRAP_BP, &int3, 0);
#ifdef CONFIG_X86_32
set_intr_gate(X86_TRAP_PF, page_fault);
#endif
next prev parent reply other threads:[~2015-02-25 11:46 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-13 5:39 [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage Wang Nan
2015-02-13 5:39 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 01/26] kprobes: set kprobes_all_disarmed earlier to enable re-optimization Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 02/26] kprobes: makes kprobes/enabled works correctly for optimized kprobes Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 03/26] kprobes: x86: mark 2 bytes NOP as boostable Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 04/26] ftrace: don't update record flags if code modification fail Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 05/26] ftrace/x86: Ensure rec->flags no change when failure occures Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 06/26] ftrace: sort ftrace entries earlier Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 07/26] ftrace: allow search ftrace addr before ftrace fully inited Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 08/26] ftrace: enable make ftrace nop before ftrace_init() Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 09/26] ftrace: allow fixing code update failure by notifier chain Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 10/26] ftrace: x86: try to fix ftrace when ftrace_replace_code Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 11/26] early kprobes: introduce kprobe_is_early for futher early kprobe use Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 12/26] early kprobes: Add an KPROBE_FLAG_EARLY for early kprobe Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 13/26] early kprobes: ARM: directly modify code Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 14/26] early kprobes: ARM: introduce early kprobes related code area Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 15/26] early kprobes: x86: directly modify code Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-20 4:00 ` Masami Hiramatsu
2015-02-20 4:00 ` Masami Hiramatsu
2015-02-13 5:40 ` [RFC PATCH v3 16/26] early kprobes: x86: introduce early kprobes related code area Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:40 ` [RFC PATCH v3 17/26] early kprobes: introduces macros for allocing early kprobe resources Wang Nan
2015-02-13 5:40 ` Wang Nan
2015-02-13 5:41 ` [RFC PATCH v3 18/26] early kprobes: allows __alloc_insn_slot() from early kprobes slots Wang Nan
2015-02-13 5:41 ` Wang Nan
2015-02-13 5:41 ` [RFC PATCH v3 19/26] early kprobes: perhibit probing at early kprobe reserved area Wang Nan
2015-02-13 5:41 ` Wang Nan
2015-02-13 5:41 ` [RFC PATCH v3 20/26] early kprobes: core logic of eraly kprobes Wang Nan
2015-02-13 5:41 ` Wang Nan
2015-02-13 5:41 ` [RFC PATCH v3 21/26] early kprobes: add CONFIG_EARLY_KPROBES option Wang Nan
2015-02-13 5:41 ` Wang Nan
2015-02-13 5:41 ` [RFC PATCH v3 22/26] early kprobes: introduce arch_fix_ftrace_early_kprobe() Wang Nan
2015-02-13 5:41 ` Wang Nan
2015-02-13 5:41 ` [RFC PATCH v3 23/26] early kprobes: x86: arch_restore_optimized_kprobe() Wang Nan
2015-02-13 5:41 ` Wang Nan
2015-02-13 5:41 ` [RFC PATCH v3 24/26] early kprobes: core logic to support early kprobe on ftrace Wang Nan
2015-02-13 5:41 ` Wang Nan
2015-02-13 5:41 ` [RFC PATCH v3 25/26] early kprobes: introduce kconfig option " Wang Nan
2015-02-13 5:41 ` Wang Nan
2015-02-13 5:41 ` [RFC PATCH v3 26/26] kprobes: enable 'ekprobe=' cmdline option for early kprobes Wang Nan
2015-02-13 5:41 ` Wang Nan
2015-02-20 3:59 ` [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage Masami Hiramatsu
2015-02-20 3:59 ` Masami Hiramatsu
2015-02-25 11:11 ` Wang Nan
2015-02-25 11:11 ` Wang Nan
2015-02-25 11:46 ` Wang Nan [this message]
2015-02-25 11:46 ` Wang Nan
-- strict thread matches above, loose matches on Subject: below --
2015-02-12 12:17 [RFC PATCH v2 " Wang Nan
2015-02-13 5:38 ` [RFC PATCH v3 " Wang Nan
2015-02-13 5:38 ` Wang Nan
2015-02-13 17:15 ` Steven Rostedt
2015-02-13 17:15 ` 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=54EDB629.4020908@huawei.com \
--to=wangnan0@huawei.com \
--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 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.