linux-toradex.git/arch/x86/kernel/hw_breakpoint.c, branch v4.2.7

perf/x86: Remove get_hbp_len and replace with bp_len

2014-12-03T14:14:30+00:00

Clean up the logic for determining the breakpoint length

Signed-off-by: Jacob Shin 
Signed-off-by: Suravee Suthikulpanit 
Acked-by: Jiri Olsa 
Reviewed-by: Oleg Nesterov 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: xiakaixu 
Signed-off-by: Frederic Weisbecker

perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8

2014-12-03T14:14:26+00:00

Implement hardware breakpoint address mask for AMD Family 16h and
above processors. CPUID feature bit indicates hardware support for
DRn_ADDR_MASK MSRs. These masks further qualify DRn/DR7 hardware
breakpoint addresses to allow matching of larger addresses ranges.

Valuable advice and pseudo code from Oleg Nesterov 

Signed-off-by: Jacob Shin 
Signed-off-by: Suravee Suthikulpanit 
Acked-by: Jiri Olsa 
Reviewed-by: Oleg Nesterov 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: xiakaixu 
Signed-off-by: Frederic Weisbecker

x86: Replace __get_cpu_var uses

2014-08-26T17:45:49+00:00

__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x).  This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.

Other use cases are for storing and retrieving data from the current
processors percpu area.  __get_cpu_var() can be used as an lvalue when
writing data or on the right side of an assignment.

__get_cpu_var() is defined as :

#define __get_cpu_var(var) (*this_cpu_ptr(&(var)))

__get_cpu_var() always only does an address determination. However, store
and retrieve operations could use a segment prefix (or global register on
other platforms) to avoid the address calculation.

this_cpu_write() and this_cpu_read() can directly take an offset into a
percpu area and use optimized assembly code to read and write per cpu
variables.

This patch converts __get_cpu_var into either an explicit address
calculation using this_cpu_ptr() or into a use of this_cpu operations that
use the offset.  Thereby address calculations are avoided and less registers
are used when code is generated.

Transformations done to __get_cpu_var()

1. Determine the address of the percpu instance of the current processor.

	DEFINE_PER_CPU(int, y);
	int *x = &__get_cpu_var(y);

    Converts to

	int *x = this_cpu_ptr(&y);

2. Same as #1 but this time an array structure is involved.

	DEFINE_PER_CPU(int, y[20]);
	int *x = __get_cpu_var(y);

    Converts to

	int *x = this_cpu_ptr(y);

3. Retrieve the content of the current processors instance of a per cpu
variable.

	DEFINE_PER_CPU(int, y);
	int x = __get_cpu_var(y)

   Converts to

	int x = __this_cpu_read(y);

4. Retrieve the content of a percpu struct

	DEFINE_PER_CPU(struct mystruct, y);
	struct mystruct x = __get_cpu_var(y);

   Converts to

	memcpy(&x, this_cpu_ptr(&y), sizeof(x));

5. Assignment to a per cpu variable

	DEFINE_PER_CPU(int, y)
	__get_cpu_var(y) = x;

   Converts to

	__this_cpu_write(y, x);

6. Increment/Decrement etc of a per cpu variable

	DEFINE_PER_CPU(int, y);
	__get_cpu_var(y)++

   Converts to

	__this_cpu_inc(y)

Cc: Thomas Gleixner 
Cc: x86@kernel.org
Acked-by: H. Peter Anvin 
Acked-by: Ingo Molnar 
Signed-off-by: Christoph Lameter 
Signed-off-by: Tejun Heo

kprobes, x86: Allow kprobes on text_poke/hw_breakpoint

2014-04-24T08:03:02+00:00

Allow kprobes on text_poke/hw_breakpoint because
those are not related to the critical int3-debug
recursive path of kprobes at this moment.

Signed-off-by: Masami Hiramatsu 
Reviewed-by: Steven Rostedt 
Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Fengguang Wu 
Cc: Jiri Kosina 
Cc: Oleg Nesterov 
Cc: Paul Gortmaker 
Link: http://lkml.kernel.org/r/20140417081807.26341.73219.stgit@ltc230.yrl.intra.hitachi.co.jp
Signed-off-by: Ingo Molnar

x86: Delete non-required instances of include

2014-01-07T05:25:18+00:00

None of these files are actually using any __init type directives
and hence don't need to include .  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

[ hpa: undid incorrect removal from arch/x86/kernel/head_32.S ]

Signed-off-by: Paul Gortmaker 
Link: http://lkml.kernel.org/r/1389054026-12947-1-git-send-email-paul.gortmaker@windriver.com
Signed-off-by: H. Peter Anvin

ptrace/x86: flush_ptrace_hw_breakpoint() shoule clear the virtual debug registers

2013-07-09T17:33:26+00:00

flush_ptrace_hw_breakpoint() destroys the counters set by ptrace, but
"leaks" ->debugreg6 and ->ptrace_dr7.

The problem is minor, but still it doesn't look right and flush_thread()
did this until commit 66cb59172959 ("hw-breakpoints: use the new wrapper
routines to access debug registers in process/thread code").  Now that
PTRACE_DETACH does flush_ too this makes even more sense.

Signed-off-by: Oleg Nesterov 
Cc: Benjamin Herrenschmidt 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jan Kratochvil 
Cc: Michael Neuling 
Cc: Paul Mackerras 
Cc: Paul Mundt 
Cc: Will Deacon 
Cc: Prasad 
Cc: Russell King 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

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