In the 2.6.33 kernel, the hw_breakpoint API is now used for the
performance event counters. The hw_breakpoint_handler() now consumes
the hw breakpoints that were previously set by kgdb arch specific
code. In order for kgdb to work in conjunction with this core API
change, kgdb must use some of th
This patch fixes the regression in functionality where the kernel
debugger and the perf API do not nicely share hw breakpoint
reservations.
The kernel debugger cannot use any mutex_lock() calls because it can
start the kernel running from an invalid context.
A mutex free version of the reservatio
Linus, please pull the kgdb git tree fixes for 2.6.33-rc5
git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
for_linus
Summary:
* Fix the kgdb regression in functionality caused by the new hw
breakpoint API changes in 2.6.33.
This leaves us with some cleanup in
On Thu, Jan 28, 2010 at 02:23:13PM -0600, Jason Wessel wrote:
> Frederic Weisbecker wrote:
> > On Thu, Jan 28, 2010 at 01:58:26PM -0600, Jason Wessel wrote:
> >
> >> New version which loses the call back registration, because if we
> >> register as a different breakpoint type, perf won't reject
On Thu, Jan 28, 2010 at 02:27:54PM -0600, Jason Wessel wrote:
> I'll move this to the gdbstub in the next merge window, because it looks
> like there might also be other archs that gain the
> arch/*/kernel/hw_breakpoint.c.
Yeah, PowerPc, S390 and ARM are in progress.
> I can also move the logic
Frederic Weisbecker wrote:
> On Thu, Jan 28, 2010 at 01:58:26PM -0600, Jason Wessel wrote:
>
>> New version which loses the call back registration, because if we
>> register as a different breakpoint type, perf won't reject it.
>>
>
>
>
> I don't understand what you mean here.
>
>
>
>
T
Frederic Weisbecker wrote:
>> If it fails the debugger tried to remove it again later. It seems to
>> me like it is a don't care corner case. You get a printk if it ever
>> does happen (which it really shouldn't).
>
>
>
> Yeah truly it's a corner case, especially if the debugger can handle
Frederic Weisbecker wrote:
> On Thu, Jan 28, 2010 at 11:44:52AM -0600, Jason Wessel wrote:
>
>> Frederic Weisbecker wrote:
>>
>>> Good simplification, but that doesn't appear related to kgdb,
>>> this should be done in a separate patch, for the perf/core tree.
>>>
>>>
>>>
>> Speci
On Thu, Jan 28, 2010 at 01:58:26PM -0600, Jason Wessel wrote:
> New version which loses the call back registration, because if we
> register as a different breakpoint type, perf won't reject it.
I don't understand what you mean here.
> I didn't
> see that loop hole in the API the first time
On Thu, Jan 28, 2010 at 11:49:14AM -0600, Jason Wessel wrote:
> Frederic Weisbecker wrote:
> >> +static int hw_break_release_slot(int breakno)
> >> +{
> >> + struct perf_event **pevent;
> >> + int ret;
> >> + int cpu;
> >> +
> >> + for_each_online_cpu(cpu) {
> >> + pevent = per_cpu_ptr
On Thu, Jan 28, 2010 at 11:44:52AM -0600, Jason Wessel wrote:
> Frederic Weisbecker wrote:
> > Good simplification, but that doesn't appear related to kgdb,
> > this should be done in a separate patch, for the perf/core tree.
> >
> >
>
> Specifically this is required so that kgdb can modify the
New version which loses the call back registration, because if we
register as a different breakpoint type, perf won't reject it. I didn't
see that loop hole in the API the first time around.
Also the dr7 fixup in hw_breakpoint.c is not needed.
The trickery for entering twice into the __kgdb_noti
Frederic Weisbecker wrote:
> On Wed, Jan 27, 2010 at 04:25:24PM -0600, Jason Wessel wrote:
>
>> The kernel debugger cannot use any mutex_lock() calls because it can
>> start the kernel running from an invalid context.
>>
>> The possibility for a breakpoint reservation to be concurrently
>> proce
Frederic Weisbecker wrote:
> On Mon, Jan 25, 2010 at 10:26:37PM -0600, Jason Wessel wrote:
>
>> @@ -466,7 +466,7 @@ static int __kprobes hw_breakpoint_handler(struct
>> die_args *args)
>> {
>> int i, cpu, rc = NOTIFY_STOP;
>> struct perf_event *bp;
>> -unsigned long dr7, dr6;
>>
On Wed, Jan 27, 2010 at 04:25:24PM -0600, Jason Wessel wrote:
> The kernel debugger cannot use any mutex_lock() calls because it can
> start the kernel running from an invalid context.
>
> The possibility for a breakpoint reservation to be concurrently
> processed at the time that kgdb interrupts
On Mon, Jan 25, 2010 at 10:26:37PM -0600, Jason Wessel wrote:
> @@ -466,7 +466,7 @@ static int __kprobes hw_breakpoint_handler(struct
> die_args *args)
> {
> int i, cpu, rc = NOTIFY_STOP;
> struct perf_event *bp;
> - unsigned long dr7, dr6;
> + unsigned long dr6;
> unsig
16 matches
Mail list logo
