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

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

Frederic Weisbecker wrote:
> On Sat, Dec 12, 2009 at 03:01:58PM -0600, Jason Wessel wrote:
>   
>> Ingo Molnar wrote:
>>     
>>> 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?
>>     
>
>
>
> We could probably have a helper that allocates a disabled breakpoint
> without reserving it.

I worked around that restriction for now, in the current version of the
kgdb patches.  When kgdb registers with the die notifier in its init
phase, it allocates the perf structures via the perf API and
subsequently disables the breakpoints with the low level API.

>  But the problem remains: you'll need to take
> locks when you eventually reserve it and when you activate it.
>
> The fact that it can happen from nmi is really a problem.
>
>   

I talked with Jan a bit with respect to this problem.  He recommended to
possibly allow kgdb to obtain hw breakpoints locklessly and to break
reservations that exist with the low level API.  The current patch in
the kgdb series does not break reservations, it only uses a slot that is
not already in use.  Let us call the scenarios A and B.

A) allow kgdb to break existing reservations
B) kgdb can use what is not reserved, without locks

What is missing right now is a notification mechanism and a separate
count for the debugger as to what is in use.   I tend to think that B is
the right default approach, but Jan was leaning towards scenario A.

> Is there any possibility that we know the user has started a
> kgdb session, and then reserve as much hardware breakpoints
> as we can in kgdb at this time?
>
>   

That is the way I implemented it the first time.  Reserve all the slots,
and then nothing else could use them.  That didn't work out too well
because then the user space could not make use of hw breakpoints,
granted this never worked before with user space + kernel space sharing
between ptrace and kgdb.

Jason.