linux-kernel - [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-next>] [day] [month] [year] [list]

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

I'll lead with a question.  Are the people making the Perf API changes
booting allyesconfig kernels?

The regression tests built into the kernel for kgdb fail as a result of
the perf API changes and can result in a hard kernel hang.  My hope
would have been that someone would have reported the problem, created a
patch to disable the test that hangs the kernel, or to fix kgdb such
that it works with the API changes.  Likewise, if there are tests I
should run to regression test the changes to the perf API, I would like
to know since we all want to make use of the same hw resource.

A patch has been included in this mail which allows kgdb to pass the
internal regression tests for hw breakpoints.  I would like to get some
comments or start a discussion as to how to solve this problem in the
2.6.33 cycle, as it is a regression in functionality.

I did not address this in the patch, but I found that the
hw_breakpoint.c API is lacking a function to query if there is a
breakpoint slot available on every processor, while atomic.  Having that
would allow an end user to see an error generated up to gdb that there
are not enough breakpoints available, as opposed to finding out about it
via a printk message after you resume the system.

Thanks,
Jason.

View attachment "x86-breakpoints-repair.patch" of type "text/x-diff" (10501 bytes)