Re: [PATCH v14 05/14] x86/hw_breakpoints: Add arch_modify_local_hw_breakpoint_addr() API
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date: 2026-09-06 15:42:24
Also in:
linux-perf-users, sashiko-reviews
On Sun, 30 Aug 2026 14:38:48 +0000 sashiko-bot@kernel.org wrote:
quoted
+int arch_modify_local_hw_breakpoint_addr(struct perf_event *bp, + unsigned long addr) +{[ ... ]quoted
+ do { + seq = this_cpu_inc_return(cpu_dr7_seq); + this_cpu_write(cpu_debugreg[i], addr); + barrier(); + set_debugreg(addr, i);[Severity: High] Does this code risk violating the x86 hardware architecture specification? Looking at arch_modify_local_hw_breakpoint_addr() in arch/x86/kernel/hw_breakpoint.c, set_debugreg() directly updates the debug address register (DR0-DR3) while its corresponding enable bit in DR7 might still be set. According to hardware specs, modifying a debug address register without first disabling the breakpoint in DR7 can lead to spurious debug exceptions or unpredictable processor behavior if an NMI occurs or if execution boundaries trigger a match on the transient state. Should the DR7 enable bit be cleared before updating the debug register?
For the wprobe, the handler will check the spurious exception, but it is better to make it safer. I will update arch_modify_local_hw_breakpoint_addr() to temporarily clear the slot's enable bit in DR7 before writing the new address, and re-enable it afterward within the cpu_dr7_seq loop. Thank you! -- Masami Hiramatsu (Google) [off-list ref]