kernel.git/arch/powerpc/kernel/hw_breakpoint.c, branch linux-3.8.y

powerpc: Dynamically calculate the dabrx based on kernel/user/hypervisor

2012-09-09T23:59:13Z

Currently we mark the DABRX to interrupt on all matches (hypervisor/kernel/user and then filter in software. We can be a lot smarter now that we can set the DABRX dynamically. This sets the DABRX based on the flags passed by the user. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt

powerpc: Rework set_dabr so it can take a DABRX value as well

2012-09-09T23:59:10Z

Rework set_dabr to take a DABRX value as well. Both the pseries and PS3 hypervisors do some checks on the DABRX values that are passed in the hcall. This patch stops bogus values from being passed to hypervisor. Also, in the case where we are clearing the breakpoint, where DABR and DABRX are zero, we modify the DABRX value to make it valid so that the hcall won't fail. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt

powerpc: Use consistent name info for arch_hw_breakpoint

2012-09-07T01:44:39Z

Change bp_info to info to be consistent with the rest of this file. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt

powerpc: Fix null pointer deref in perf hardware breakpoints

2012-08-24T10:26:04Z

Currently if you are doing a global perf recording with hardware breakpoints (ie perf record -e mem:0xdeadbeef -a), you can oops with: Faulting instruction address: 0xc000000000738890 cpu 0xc: Vector: 300 (Data Access) at [c0000003f76af8d0] pc: c000000000738890: .hw_breakpoint_handler+0xa0/0x1e0 lr: c000000000738830: .hw_breakpoint_handler+0x40/0x1e0 sp: c0000003f76afb50 msr: 8000000000001032 dar: 6f0 dsisr: 42000000 current = 0xc0000003f765ac00 paca = 0xc00000000f262a00 softe: 0 irq_happened: 0x01 pid = 6810, comm = loop-read enter ? for help [c0000003f76afbe0] c00000000073cd04 .notifier_call_chain.isra.0+0x84/0xe0 [c0000003f76afc80] c00000000073cdbc .notify_die+0x3c/0x60 [c0000003f76afd20] c0000000000139f0 .do_dabr+0x40/0xf0 [c0000003f76afe30] c000000000005a9c handle_dabr_fault+0x14/0x48 --- Exception: 300 (Data Access) at 0000000010000480 SP (ff8679e0) is in userspace This is because we don't check to see if the break point is associated with task before we deference the task_struct pointer. This changes the update to use current. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt

powerpc/hw_breakpoints: Fix incorrect pointer access

2012-07-11T04:20:20Z

If arch_validate_hwbkpt_settings() fails, bp->ctx won't be valid and the kernel panics. Add a check to fix this. Reported-by: Edjunior Barbosa Machado Signed-off-by: Naveen N. Rao Signed-off-by: Benjamin Herrenschmidt

powerpc: remove non-required uses of include

2011-10-31T23:30:44Z

None of the files touched here are modules, and they are not exporting any symbols either -- so there is no need to be including the module.h. Builds of all the files remains successful. Even kernel/module.c does not need to include it, since it includes linux/moduleloader.h instead. Signed-off-by: Paul Gortmaker

powerpc, hw_breakpoint: Tell generic code we have no instruction breakpoints

2010-06-30T03:54:58Z

At present, hw_breakpoint_slots() returns 1 regardless of what type of breakpoint is specified in the type argument. Since we don't define CONFIG_HAVE_MIXED_BREAKPOINTS_REGS, there are separate values for TYPE_INST and TYPE_DATA, and hw_breakpoint_slots() returns 1 for both, effectively advertising instruction breakpoint support which doesn't exist. This fixes it by making hw_breakpoint_slots return 1 for TYPE_DATA and 0 for TYPE_INST. This moves hw_breakpoint_slots() from the powerpc hw_breakpoint.h to hw_breakpoint.c because the definitions of TYPE_INST and TYPE_DATA aren't available in . They are defined in but we can't include that header in , and nor can we rely on being included before . Since hw_breakpoint_slots() is only called at boot time, there is no performance impact from making it a real function rather than a static inline. Signed-off-by: Paul Mackerras

powerpc, hw_breakpoint: Cooperate better with other single-steppers

2010-06-23T05:46:55Z

The code we had to clear the MSR_SE bit was not doing anything because the caller (ultimately single_step_exception() in traps.c) had already cleared. Instead of trying to leave MSR_SE set if the TIF_SINGLESTEP flag is set (which indicates that the process is being single-stepped by ptrace), we instead return NOTIFY_DONE in that case, which means the caller will generate a SIGTRAP for the process. Signed-off-by: Paul Mackerras

powerpc, hw_breakpoint: Fix off-by-one in checking access address

2010-06-23T05:42:43Z

The code would accept an access to an address one byte past the end of the requested range as legitimate, due to having a "<=" rather than a "<". This fixes that and cleans up the code a bit. Signed-off-by: Paul Mackerras

powerpc, hw_breakpoint: Discard extraneous interrupt due to accesses outside symbol length

2010-06-22T09:40:51Z

Many a times, the requested breakpoint length can be less than the fixed breakpoint length i.e. 8 bytes supported by PowerPC 64-bit server (Book III S) processors. This could lead to extraneous interrupts resulting in false breakpoint notifications. This detects and discards such interrupts for non-ptrace requests. We don't change ptrace behaviour to avoid breaking compatability. [Suggestion from Paul Mackerras to add a new flag in 'struct arch_hw_breakpoint' to identify extraneous interrupts] Signed-off-by: K.Prasad Signed-off-by: Paul Mackerras