linux-toradex.git/arch/x86/kernel/hw_breakpoint.c, branch v3.2.34

x86: Use this_cpu_ops to optimize code

2010-12-30T11:20:28+00:00

Go through x86 code and replace __get_cpu_var and get_cpu_var
instances that refer to a scalar and are not used for address
determinations.

Cc: Yinghai Lu 
Cc: Ingo Molnar 
Acked-by: Tejun Heo 
Acked-by: "H. Peter Anvin" 
Signed-off-by: Christoph Lameter 
Signed-off-by: Tejun Heo

x86: Ignore trap bits on single step exceptions

2010-11-12T13:51:01+00:00

When a single step exception fires, the trap bits, used to
signal hardware breakpoints, are in a random state.

These trap bits might be set if another exception will follow,
like a breakpoint in the next instruction, or a watchpoint in the
previous one. Or there can be any junk there.

So if we handle these trap bits during the single step exception,
we are going to handle an exception twice, or we are going to
handle junk.

Just ignore them in this case.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=21332

Reported-by: Michael Stefaniuc 
Signed-off-by: Frederic Weisbecker 
Cc: Rafael J. Wysocki 
Cc: Maciej Rutecki 
Cc: Alexandre Julliard 
Cc: Jason Wessel 
Cc: All since 2.6.33.x

x86: Fix instruction breakpoint encoding

2010-09-17T01:24:13+00:00

Lengths and types of breakpoints are encoded in a half byte
into CPU registers. However when we extract these values
and store them, we add a high half byte part to them: 0x40 to the
length and 0x80 to the type.
When that gets reloaded to the CPU registers, the high part
is masked.

While making the instruction breakpoints available for perf,
I zapped that high part on instruction breakpoint encoding
and that broke the arch -> generic translation used by ptrace
instruction breakpoints. Writing dr7 to set an inst breakpoint
was then failing.

There is no apparent reason for these high parts so we could get
rid of them altogether. That's an invasive change though so let's
do that later and for now fix the problem by restoring that inst
breakpoint high part encoding in this sole patch.

Reported-by: Kelvie Wong 
Signed-off-by: Frederic Weisbecker 
Cc: Prasad 
Cc: Mahesh Salgaonkar 
Cc: Will Deacon

x86: Support for instruction breakpoints

2010-06-24T21:35:27+00:00

Instruction breakpoints need to have a specific length of 0 to
be working. Bring this support but also take care the user is not
trying to set an unsupported length, like a range breakpoint for
example.

Signed-off-by: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: Paul Mackerras 
Cc: Prasad 
Cc: Mahesh Salgaonkar 
Cc: Will Deacon 
Cc: Jason Wessel

x86: Set resume bit before returning from breakpoint exception

2010-06-24T21:35:15+00:00

Instruction breakpoints trigger before the instruction executes,
and returning back from the breakpoint handler brings us again
to the instruction that breakpointed. This naturally bring to
a breakpoint recursion.

To solve this, x86 has the Resume Bit trick. When the cpu flags
have the RF flag set, the next instruction won't trigger any
instruction breakpoint, and once this instruction is executed,
RF is cleared back.

This let's us jump back to the instruction that triggered the
breakpoint without recursion.

Use this when an instruction breakpoint triggers.

Signed-off-by: Frederic Weisbecker 
Cc: Will Deacon 
Cc: Prasad 
Cc: Mahesh Salgaonkar 
Cc: Paul Mackerras 
Cc: Ingo Molnar 
Cc: Jason Wessel

hw-breakpoints: Change/Enforce some breakpoints policies

2010-05-01T02:32:10+00:00

The current policies of breakpoints in x86 and SH are the following:

- task bound breakpoints can only break on userspace addresses
- cpu wide breakpoints can only break on kernel addresses

The former rule prevents ptrace breakpoints to be set to trigger on
kernel addresses, which is good. But as a side effect, we can't
breakpoint on kernel addresses for task bound breakpoints.

The latter rule simply makes no sense, there is no reason why we
can't set breakpoints on userspace while performing cpu bound
profiles.

We want the following new policies:

- task bound breakpoint can set userspace address breakpoints, with
no particular privilege required.
- task bound breakpoints can set kernelspace address breakpoints but
must be privileged to do that.
- cpu bound breakpoints can do what they want as they are privileged
already.

To implement these new policies, this patch checks if we are dealing
with a kernel address breakpoint, if so and if the exclude_kernel
parameter is set, we tell the user that the breakpoint is invalid,
which makes a good generic ptrace protection.
If we don't have exclude_kernel, ensure the user has the right
privileges as kernel breakpoints are quite sensitive (risk of
trap recursion attacks and global performance impacts).

[ Paul Mundt: keep addr space check for sh signal delivery and fix
  double function declaration]

Signed-off-by: Frederic Weisbecker 
Cc: Will Deacon 
Cc: Mahesh Salgaonkar 
Cc: K. Prasad 
Cc: Paul Mundt 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Jason Wessel 
Cc: Ingo Molnar 
Signed-off-by: Paul Mundt

Merge branch 'perf/core' into perf/urgent

2010-03-04T10:47:52+00:00

Merge reason: Switch from pre-merge topical split to the post-merge urgent track

Signed-off-by: Ingo Molnar

hw-breakpoints: Remove stub unthrottle callback

2010-02-28T19:51:15+00:00

We support event unthrottling in breakpoint events. It means
that if we have more than sysctl_perf_event_sample_rate/HZ,
perf will throttle, ignoring subsequent events until the next
tick.

So if ptrace exceeds this max rate, it will omit events, which
breaks the ptrace determinism that is supposed to report every
triggered breakpoints. This is likely to happen if we set
sysctl_perf_event_sample_rate to 1.

This patch removes support for unthrottling in breakpoint
events to break throttling and restore ptrace determinism.

Signed-off-by: Frederic Weisbecker 
Cc: 2.6.33.x 
Cc: Peter Zijlstra 
Cc: K.Prasad 
Cc: Paul Mackerras

x86/hw-breakpoints: Remove the name field

2010-02-27T16:24:15+00:00

Remove the name field from the arch_hw_breakpoint. We never deal
with target symbols in the arch level, neither do we need to ever
store it. It's a legacy for the previous version of the x86
breakpoint backend.

Let's remove it.

Signed-off-by: Frederic Weisbecker 
Cc: K.Prasad 
Cc: Linus Torvalds

Merge commit 'v2.6.33' into perf/core

2010-02-27T15:18:46+00:00

Merge reason:
	__percpu annotations need the corresponding sparse address
space definition upstream.

Conflicts:
	tools/perf/util/probe-event.c (trivial)