Messages in this thread | | | Date | Mon, 28 Jan 2008 12:22:36 -0500 | From | Masami Hiramatsu <> | Subject | Re: [PATCH 3/3] x86: WARN_ON breakpoints from .kprobes.text section |
| |
Hi,
Abhishek Sagar wrote: > On 1/28/08, Masami Hiramatsu <mhiramat@redhat.com> wrote: >> Thank you for explanation, I hope I can understand it. >> Even if it causes a trap recursively, it could be checked (and ignored) by >> longjump_break_handler(), and passed to the debugger correctly. > > Yes, all non-kprobe breakpoints are left to the kernel to be handled. > The objective here is to intercept the trap handling of a certain > category of such breakpoints and emit a warning. The premise being > that .kprobes.text section is a logical breakpoint-free zone.
Oh, I think I've gotten what misleads you. The .kprobes.text section is a KPROBES-FREE zone. There may be breakpoints owned by other debuggers and hand-coded breakpoints (like as jprobe_return).
>> Please consider that someone expands jprobe(jprobe2) which uses >> jprobe_return2() instead of jprobe_return(), how would you handle it? > > By a simple modification of is_jprobe_bkpt() (defined in patch #2 of > this series).
IMO, one of advantages of current logic is that you can add another break_handler-based probe as an module without any patches. Even if someone makes fooprobe which is not a jprobe variant, current logic can treat it correctly. (Another advantage is the performance. Current logic checks only if there is a running kprobe and there is no kprobes related to the trapped address, instead of checking address section every time when each breakpoint is hit.)
>> Current kprobes provides an opportunity to those external probe frameworks >> for checking it by themselves. > > Could you clarirfy this with some example. For now I'm assuming that > by external probe frameworks you mean kernel modules using kprobes.
Yes, I mentioned it above.
> If > they embed breakpoints in their handlers, then they will simply not be > caught by this check because thay cannot lie in the .kprobes.text > section.
They cannot lie kprobes in the .kprobes.text section, but can put breakpoints by hand. this is the reason why kprobes provides break_handler.
Thanks, Best Regards,
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division
e-mail: mhiramat@redhat.com
| |