Re: [PATCH v7 06/10] x86/hw_breakpoint: Unify breakpoint install/uninstall

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing compiler memory barrier during hardware breakpoint disable allows reordering that breaks NMI safety.
--

--- Patch [6]: [PATCH v7 06/10] x86/hw_breakpoint: Unify breakpoint install/uninstall ---
Note: The format of this review has been altered to a free-form summary due to restrictions on quoting the original patch text.

commit 16356ea39e4e8d100873d56e9298c633a58cb692
Author: Jinchao Wang <wangjinchao600@gmail.com>
x86/hw_breakpoint: Unify breakpoint install/uninstall

This patch consolidates breakpoint management to reduce code duplication and
binary size. It introduces manage_bp_slot() and setup_hwbp() to handle the
logic previously duplicated in install and uninstall functions.

File: arch/x86/kernel/hw_breakpoint.c
Function: setup_hwbp()

[Severity: High]
Could the repositioning of the barrier() in the disable path introduce a
race condition with NMI handlers?

In setup_hwbp(), when enable is false, the code writes to the per-CPU cpu_dr7
cache after updating the hardware DR7 register via set_debugreg(). However,
the barrier() call was placed before set_debugreg().

Since neither the native set_debugreg() nor this_cpu_write() provides a
compiler memory clobber by default, is the compiler permitted to reorder
this_cpu_write(cpu_dr7, dr7) to occur before the hardware set_debugreg()
update?

If an NMI interrupts exactly between the reordered memory write to cpu_dr7
and the hardware DR7 register update, the NMI entry code (local_db_save)
would observe cpu_dr7 as zero and skip clearing the hardware DR7 register.
If the NMI handler then touches the watched address, would this trigger an
infinite #DB exception recursion and crash the system?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/178407983818.95826.12714571928538799781.stgit@devnote2?part=6