public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "K.Prasad" <prasad@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, stern@rowland.harvard.edu,
	roland@redhat.com, mingo@elte.hu, richardj_moore@uk.ibm.com,
	naren@linux.vnet.ibm.com
Subject: Re: [RFC Patch 0/9] Hardware Breakpoint interfaces - v4
Date: Wed, 28 Jan 2009 23:38:15 +0530	[thread overview]
Message-ID: <20090128180815.GA4563@in.ibm.com> (raw)
In-Reply-To: <20090127161518.88ac3f1c.akpm@linux-foundation.org>

On Tue, Jan 27, 2009 at 04:15:18PM -0800, Andrew Morton wrote:
> On Thu, 22 Jan 2009 19:26:40 +0530
> "K.Prasad" <prasad@linux.vnet.ibm.com> wrote:
> 
> > Hi All,
> > 	Please find the new set of patches that introduce kernel
> > interfaces to use Hardware Breakpoint registers and an implementation
> > for x86 (and x86_64) architecture, now labelled as Version IV.
> 
> What a lot of code.  It looks very readable, although I haven't read it
> yet.

Thanks for responding to the patches.

> 
> What I'm missing is a general overview: what does the feature do?  Why
> do we need it in the kernel?  What is the value?

The patchset brings in a feature to track all read or write operations
on any given kernel data location. This will be useful in narrowing down
problems such as memory corruption wherein all 'write operations' on a
given kernel variable can be easily tracked or to know the value of an
interesting variable/counter when a 'condition' (denoted again by a
variable has changed).

The framework proposed for using Hardware breakpoint registers through
this patch will eventually be extended to exploit other arch-specific
features that allow I/O breakpoints (to intercept erroneous I/O
transactions).

> 
> I see mention of converting kgdb.  OK.  But are there plans to convert
> anything else in-kernel to use this?
> 

ptrace which uses HW Breakpoint registers based on requests from
applications in user-space (typically GDB-like debuggers) have been
using the HW Breakpoint registers directly. This is now converted to use
the proposed APIs - register_user_hw_breakpoint().

> I see some exported-to-modules API for kernel developers to use (I
> assume).  It would be appropriate to add an overview of that capability
> in the [0/n] patch description.

Sure. I will provide a description of the capabilities. I eventually
plan an addition to the Documentation/ directory with detailed
explanation.

> 
> Similarly I see something about "user breakpoints" but I'm not seeing
> any description of what they are, nor how they are used, nor what value
> they bring, etc.

The reason being that the register_user_hw_breakpoint() interface hasn't
been exported currently, atleast not in the first iteration of
submission. The only in-kernel user would be ptrace which will invoke
the worker routine __register_user_hw_breakpoint() directly.

When exported, they will also help avoid some of the problems arising
 due to the fine-granular approach taken by ptrace towards HW registers
(which needs a new syscall for every register-write. For e.g., two
syscalls will be required to set a breakpoint in x86, one to write the
address and the other to enable control register dr7).

> 
> 
> IOW, we need the glossy sales brochure, please.a

Certainly. My next set of patches, which should fix the issue in
creating user-space breakpoints will contain a descriptive [Patch 0/n]
and will eventually contain a Documentation/hw_breakpoint.txt.

Thanks,
K.Prasad
 

      reply	other threads:[~2009-01-28 18:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-22 13:56 [RFC Patch 0/9] Hardware Breakpoint interfaces - v4 K.Prasad
2009-01-22 14:00 ` [RFC Patch 1/10] Introducing generic hardware breakpoint handler interfaces K.Prasad
2009-01-29  3:55   ` Paul E. McKenney
2009-01-30 11:19     ` K.Prasad
2009-01-30 15:55       ` Alan Stern
2009-02-01 13:54         ` Paul E. McKenney
2009-02-01 18:05           ` Alan Stern
2009-02-03 17:23             ` K.Prasad
2009-02-03 20:07               ` Alan Stern
2009-01-22 14:04 ` [RFC Patch 2/10] x86 architecture implementation of Hardware Breakpoint interfaces K.Prasad
2009-01-22 14:05 ` [RFC Patch 3/10] Modifying generic debug exception to use virtual debug registers K.Prasad
2009-01-22 14:05 ` [RFC Patch 4/10] Modify kprobe exception handler to recognise single-stepping by HW Breakpoint handler K.Prasad
2009-01-22 14:06 ` [RFC Patch 5/10] Use wrapper routines around debug registers in processor related functions K.Prasad
2009-01-22 14:07 ` [RFC Patch 6/10] Use virtual debug registers in process/thread handling code K.Prasad
2009-01-22 14:08 ` [RFC Patch 7/10] Modify signal handling code to refrain from re-enabling HW Breakpoints K.Prasad
2009-01-22 14:09 ` [RFC Patch 8/10] Modify Ptrace routines to access breakpoint registers K.Prasad
2009-01-22 14:10 ` [RFC Patch 9/10] Cleanup HW Breakpoint registers before kexec K.Prasad
2009-01-22 14:12 ` [RFC Patch 10/10] Sample HW breakpoint over kernel data address K.Prasad
2009-01-22 15:42 ` [RFC Patch 0/9] Hardware Breakpoint interfaces - v4 Alan Stern
2009-01-23 11:07   ` K.Prasad
2009-01-29  7:05     ` K.Prasad
2009-01-28  0:15 ` Andrew Morton
2009-01-28 18:08   ` K.Prasad [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=20090128180815.GA4563@in.ibm.com \
    --to=prasad@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=naren@linux.vnet.ibm.com \
    --cc=richardj_moore@uk.ibm.com \
    --cc=roland@redhat.com \
    --cc=stern@rowland.harvard.edu \
    /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