linux-kernel - Re: [PATCH 4/6] hw-breakpoints: Rewrite the hw-breakpoints layer on top of perf events

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]

Date:	Thu, 5 Nov 2009 10:59:44 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Prasad <prasad@...ux.vnet.ibm.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jan Kiszka <jan.kiszka@....de>,
	Jiri Slaby <jirislaby@...il.com>,
	Li Zefan <lizf@...fujitsu.com>, Avi Kivity <avi@...hat.com>,
	Mike Galbraith <efault@....de>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH 4/6] hw-breakpoints: Rewrite the hw-breakpoints layer on top of perf events

Frederic Weisbecker writes:

> This patch rebase the implementation of the breakpoints API on top of
> perf events instances.
> 
> Each breakpoints are now perf events that handle the
> register scheduling, thread/cpu attachment, etc..

What I haven't managed to understand yet is how you provide reliable
breakpoints for debugging purposes.  If I'm debugging a program and I
have set a breakpoint, I'll be very unhappy if the breakpoint should
trigger but doesn't because the perf_event infrastructure has decided
it can't schedule that breakpoint in.  If the breakpoint isn't going
to work then I want to know that at the time that I set it.

We can go some distance towards that with the pinned attribute, but
not far enough.  The pinned attribute doesn't guarantee that the event
will always be scheduled in, it just says that we'll do our best to
schedule it in, and if we can't, we'll put the event into error state
so that the user knows we didn't manage to schedule it in.  But
there's no way to get back to gdb and tell it that a breakpoint that
it had previously successfully created is no longer working.

Also, we don't currently fail the creation of a pinned event if it
would conflict with another pinned event already created in the same
context.  We would need to do something like that if we want to use
pinned events for debugging breakpoints (as distinct from breakpoints
for performance monitoring purposes, for which it matters less if they
are sometimes not scheduled in).

And then there's the question of whether a per-cpu pinned breakpoint
event conflicts with a per-task pinned breakpoint event if you only
have one breakpoint register (as is the case on Power server CPUs).
Plus the fact that we don't currently give per-task pinned events
priority over per-cpu non-pinned events (perhaps that would be a good
idea anyway).

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/