Re: [RFC] Fix 2.6.33 x86 regression to kgdb hw breakpoints - due to perf API changes

[Jason Wessel <jason.wessel@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]

Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>   
>> Hm, the kgdb hw-breakpoint changes freshly put into v2.6.33 look 
>> pretty broken: [...]
>>     
>
> Sorry - i thought for a moment that it was introduced by this recent 
> change:
>
>   7f8b7ed: kgdb: Always process the whole breakpoint list on activate or deactivate
>
> but it's deeper than that indeed.
>
>   

Yes, the broken parts came from the perf merge.

> Basically we have two options:
>
>  A- change kgdb to use the hw-breakpoints highlevel APIs (i'd prefer 
>     that)
>
>   

Right now we can't because the high level code uses all sorts of mutexes
and sync points to get the hw breakpoints installs on the various
processors.  After I re-spun my RFC patch, I found another problem.  I
do use the high level code to create a block of 4 (struct perf_event **)
structures, but doing so ultimately calls the reserve hw breakpoint even
though they are marked as disabled when created.

Should I, or can I change that behavior?

The aim of the RFC patch was to allow kgdb to using the arch_install*
break point functions directly because they can be used atomically, and
the perf code at the high level will still not get a breakpoint if kgdb
is already using it that way, and kgdb won't squash a breakpoint that
the perf code is using.

In the ideal world the management routines could be the same, but the
problem is in the way we want to deal with the break points in kgdb
while the master and all slave cpus are effectively stopped.

>  B- or keep what we had so far: kgdb overrides existing GDB (and now 
>     perf) breakpoints
>   
This is broken today, because the perf installs itself as the lowest
priority.

If kgdb were to get a lower priority there is a way to make it work
again using the existing code. 

The RFC patch I made aligns things a little better in that at least
perf, user space, and kgdb are all pulling from the same low level
management code.  It has the desirable side effect of making user space
hw breakpoints work in conjunction with kernel space hw breakpoints
which is something that never worked before.

> I havent noticed that hw-breakpoints lock up under kgdb.
>   

I don't see the lockups all the time, it happens when using the kgdb
test suite from boot with the allyesconfig.  Or if you boot the kernel
with kgdbts=V1F100.

I think for now we might just consider turning off the hw breakpoint
code in kgdb so we don't hang kernels, until this is sorted out.  Patch
provided.

Jason.



[-- Attachment #2: hw_off.patch --]
[-- Type: text/x-diff, Size: 849 bytes --]

From: Jason Wessel <jason.wessel@windriver.com>
Subject: [PATCH] x86,kgdb: disable kgdb hw breakpoints until they are fixed

Using hw breakpoints can hang the kgdb test suite or yeild unpredictable
results while debugging due to the recent hw_breakpoint changes in
2.6.33.  Until this is fixed, disable kgdb hw breakpoint support.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
 arch/x86/kernel/kgdb.c |    1 -
 1 file changed, 1 deletion(-)

--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -576,7 +576,6 @@ unsigned long kgdb_arch_pc(int exception
 struct kgdb_arch arch_kgdb_ops = {
 	/* Breakpoint instruction: */
 	.gdb_bpt_instr		= { 0xcc },
-	.flags			= KGDB_HW_BREAKPOINT,
 	.set_hw_breakpoint	= kgdb_set_hw_break,
 	.remove_hw_breakpoint	= kgdb_remove_hw_break,
 	.remove_all_hw_break	= kgdb_remove_all_hw_break,