Message-ID: <20090210123514.GA4199@in.ibm.com>
Date:	Tue, 10 Feb 2009 18:05:14 +0530
From:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Roland McGrath <roland@...hat.com>, mingo@...e.hu,
	richardj_moore@...ibm.com, jason.wessel@...driver.com,
	prasad@...ux.vnet.ibm.com, naren@...ux.vnet.ibm.com
Subject: [Patch 0/10] Hardware Breakpoint interfaces - v2

Hi Andrew and all,

	Please find the patches that introduce interfaces to access
Hardware Breakpoint (or watchpoint) registers and an arch-specific
implementation for x86/x86_64 architecture. The earlier patchset (sent to
you here: http://lkml.org/lkml/2009/1/29/36) generated some discussion
over the employment of RCU synchronisation in the patchset. They're now
resolved. The other changes over the previous patchset include:

- Modified kernel/hw_breakpoint.c and arch/x86/kernel/hw_breakpoint.c
into independently compilable units. Made necessary declarations in
header files.

- One pair of read-side RCU locks were introduced in
load_debug_registers() following discussions about RCU synchronisation
in the patchset. 

A short description of the framework and interfaces is provided
below. Some of the details will be specific to x86/x86_64 architecture
and may vary depending upon the support provided by the target
processor.

The patches are based of -mm tree (commit
6a522c468fe6d01679224edfe78586c95b6d9872) and have been tested on x86
architecture over 2.6.29-rc2. Kindly accept these patches to be a part
of -mm tree.

Description
-------------
The Hardware Breakpoint registers can be used for tracing changes to a
variable or data location (even I/O ports in x86/x86_64) and will be
extremely helpful in debugging problems such as memory corruption. While
these registers have been used by user-space debuggers for long (through
'ptrace' syscalls), KGDB exploited them for kernel-space addresses.

The proposed framework, introduces interfaces to use them directly on
both  user- and kernel-space addresses apart from arbitrating requests
from various such users for the limited number of registers.

The interfaces are:

int register_kernel_hw_breakpoint(struct hw_breakpoint *);
void unregister_kernel_hw_breakpoint(struct hw_breakpoint *bp);

int register_user_hw_breakpoint(struct task_struct *tsk,
                                 struct hw_breakpoint *bp);
void unregister_user_hw_breakpoint(struct task_struct *tsk,
                struct hw_breakpoint *bp);

The 'struct hw_breakpoint' will be the anchor data-structure containing
all the necessary information such as name or address, type, length,
priority and pointers to handler functions (some of which are
arch-specific). More information about the role of each field, the
handler
functions and their return values can be found in the descriptive
comments
preceding these functions and in "include/asm-generic/hw_breakpoint.h".

While (un)register_user_hw_breakpoint() isn't exported yet, its
worker-routine __register_user-hw_breakpoint() is used by ptrace syscall
for all breakpoint register requirements. For the kernel-space, a simple
use case to trace 'write' operations on a kernel variable can be found
in samples/hw_breakpoint/data_breakpoint.c.

In the current patchset, support is provided only for read and
read-write breakpoints on data locations, which can be later expand to
include instruction and I/O breakpoints for x86/x86_64.

The patches are based on 2.6.29-rc2 and have been tested on an x86
machine along with concurrent sessions of a kprobe-module and a GDB
session using HW breakpoints on the target program.

There is pending integration with 'KGDB' without which mutual exclusion
between them (KGDB and HW breakpoint use through above interfaces) needs
to be observed.

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