Message-ID: <20090128180815.GA4563@in.ibm.com>
Date:	Wed, 28 Jan 2009 23:38:15 +0530
From:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, stern@...land.harvard.edu,
	roland@...hat.com, mingo@...e.hu, richardj_moore@...ibm.com,
	naren@...ux.vnet.ibm.com
Subject: Re: [RFC Patch 0/9] Hardware Breakpoint interfaces - v4

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@...ux.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
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists