linux-kernel - Re: [RFC] Fix 2.6.33 x86 regression to kgdb hw breakpoints

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B2404C6.2050003@windriver.com>
Date:	Sat, 12 Dec 2009 15:01:58 -0600
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	"K.Prasad" <prasad@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] Fix 2.6.33 x86 regression to kgdb hw breakpoints - due
 to perf API changes

Ingo Molnar wrote:
> * Ingo Molnar <mingo@...e.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.

View attachment "hw_off.patch" of type "text/x-diff" (850 bytes)