LKML Archive on
help / color / mirror / Atom feed
From: Masami Hiramatsu <>
To: Abhishek Sagar <>
Cc: LKML <>,,,
	Ingo Molnar <>
Subject: Re: [PATCH 3/3] x86: WARN_ON breakpoints from .kprobes.text section
Date: Mon, 28 Jan 2008 12:22:36 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


Abhishek Sagar wrote:
> On 1/28/08, Masami Hiramatsu <> 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.

Best Regards,

Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division


      reply	other threads:[~2008-01-28 17:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-27  9:09 Abhishek Sagar
2008-01-27 14:28 ` Masami Hiramatsu
2008-01-27 15:33   ` Abhishek Sagar
2008-01-27 22:08     ` Masami Hiramatsu
2008-01-28 11:16       ` Abhishek Sagar
2008-01-28 17:22         ` Masami Hiramatsu [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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 3/3] x86: WARN_ON breakpoints from .kprobes.text section' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).