Re: [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.
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. > I think this is almost enough for debugging, and very general because > we don't need optprobe for porting to other arch. > > And for ftrace-based kprobe, we can just put breakpoint on mcount call at > beginning. ftrace will need to check and keep it when replacing mcount-call > with nop. Afterward, we can cleanly update those kprobes with ftrace-based > kprobe. > > So, please start with smaller changes. > > Thank you, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.
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 think this is almost enough for debugging, and very general because we don't need optprobe for porting to other arch. And for ftrace-based kprobe, we can just put breakpoint on mcount call at beginning. ftrace will need to check and keep it when replacing mcount-call with nop. Afterward, we can cleanly update those kprobes with ftrace-based kprobe. So, please start with smaller changes. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.
On Fri, 13 Feb 2015 13:38:27 +0800 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: Note the 0/26 patch should contain the summary of what the entire series is trying to accomplish, and how it is trying to accomplish it. > > 1. Fixes ftrace_sort_mcount_area. Original patch doesn't work for module. > 2. Wraps setting of kprobes_initialized in stop_machine() context. > I'll be attending Linux Collaboration Summit next week and there's a lot of things I need to finish before I leave, and I wont be able to look at these while at the conference. Which means I can not take a in depth look at the patches until I get back, and even then I'll be catching up on other things. Feel free to ping me about this after Feb 23rd. >From what I can gather from skimming the patches, you attend to have a way to pass kprobes via the kernel command line or some other way that kprobes are pre allocated (called before memory management), and if they happen to be at an ftrace location, you have hooks to have ftrace notify kprobes to fix it up. Honestly, I hate the notifiers. Get rid of them. kprobes and ftrace are coupled, as kprobes must know about ftrace, and ftrace knows about kprobes. This is a very specific case. Notifiers represent a "general" use case, and I don't want something else hooking into these notifiers. This should be hard coded, and fixed up at ftrace_init(), where after ftrace_init() everything acts as it does today. That is, the early kprobes add hooks to the ftrace nop locations. When ftrace tries to convert them to nops it will notice that they do not match the call to mcount. In this case, ftrace should call a kprobes function asking if this is a call to kprobe, and if so, it will convert this location into a normal call to the ftrace trampoline that calls the early kprobe function. This will only be done during ftrace_init() when it tries to convert the calls to mcount or __fentry__ (not ftrace_caller) to nops. It will then convert it to ftrace_caller, if need be, or whatever. Perhaps that would be easier. Before doing the modifications, it could do a special register of ftrace to have the ftrace_regs_caller point to the early kprobe function and when its doing the modifications, it will be aware that there might be some locations that call the early kprobe function. Basically what I'm saying is that this is a very special case. Don't try to over engineer this into something that can be expanded by other use cases. I rather not make this easy for other use cases to connect to the ftrace locations at early boot up. That's just opening a can of worms that are spoiled, and taste like bad sushi from a restaurant with lots of neon lights. I'm not against the idea of having early kprobes, but I'm not thrilled with the current implementation. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
