The current function to manually restore breakpoints
(hw_breakpoint_restore) places the contents of the thread.debugreg6
variable back into the dr6 hardware register, a piece of hardware
intended to be read, not used as local storage. The problem with this
is that systems that register for breakpoints, including the perf
event system and kgdb/kdb, modify this variable. I have observed
garbage stacked debug statuses being cycled through dr6 and this
variable over and over again in a loop by calls to
hw_breakpoint_restore() that cause strange behaviors in kdb and this
layer. In short, I don't use this broken function.
This function is necessary because upon debugger entry, you must set
dr7 to 0 to disable breakpoints while inside the debugger then call
hw_breakpoint_restore() to reload the state and re-enable them. This
function is identical to hw_breakpoint_restore() except it leaves out
writing a user defined thread.debugreg6 variable back into a hardware
register not intended for that purpose.
Signed-off-by: Jeff V. Merkey <[email protected]>
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index 50a3fad..7ea0f78 100644
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -425,6 +425,16 @@ void hw_breakpoint_restore(void)
}
EXPORT_SYMBOL_GPL(hw_breakpoint_restore);
+void hw_breakpoint_enable(void)
+{
+ set_debugreg(__this_cpu_read(cpu_debugreg[0]), 0);
+ set_debugreg(__this_cpu_read(cpu_debugreg[1]), 1);
+ set_debugreg(__this_cpu_read(cpu_debugreg[2]), 2);
+ set_debugreg(__this_cpu_read(cpu_debugreg[3]), 3);
+ set_debugreg(__this_cpu_read(cpu_dr7), 7);
+}
+EXPORT_SYMBOL_GPL(hw_breakpoint_enable);
+
/*
* Handle debug exception notifications.
*