On Sun, 30 Aug 2026 14:38:48 +0000 [email protected] wrote: > > +int arch_modify_local_hw_breakpoint_addr(struct perf_event *bp, > > + unsigned long addr) > > +{ > > [ ... ] > > > + 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) <[email protected]>
