Re: [RFC PATCH 03/13] x86/hw_breakpoint: Add arch_reinstall_hw_breakpoint

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] In-place hardware breakpoint reinstallation via `arch_reinstall_hw_breakpoint()` fails to clear the AMD hardware breakpoint address mask when transitioning from a range breakpoint to an exact address breakpoint.
--

--- Patch [3]: [RFC PATCH 03/13] x86/hw_breakpoint: Add arch_reinstall_hw_breakpoint ---
commit 59c50868129e1541bda319c3957c2b199256f005
Author: Jinchao Wang <wangjinchao600@gmail.com>

x86/hw_breakpoint: Add arch_reinstall_hw_breakpoint

This commit introduces arch_reinstall_hw_breakpoint to allow efficient
re-establishment of existing breakpoints in atomic contexts. It also modifies
setup_hwbp to clear the slot's stale length/type and enable bits in DR7
before re-encoding to avoid OR-merging with the old encoding.

> diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
> index 877509539300c..4221dbb899f90 100644
> --- a/arch/x86/kernel/hw_breakpoint.c
> +++ b/arch/x86/kernel/hw_breakpoint.c

[ ... ]

> @@ -188,6 +195,11 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
>  	return arch_manage_bp(bp, BP_SLOT_ACTION_INSTALL);
>  }
>  
> +int arch_reinstall_hw_breakpoint(struct perf_event *bp)
> +{
> +	return arch_manage_bp(bp, BP_SLOT_ACTION_REINSTALL);
> +}

[Severity: Medium]
When arch_reinstall_hw_breakpoint is called to transition an active
breakpoint from an AMD range breakpoint to an exact address breakpoint,
does it fail to clear the old hardware breakpoint address mask?

If the caller updates the breakpoint configuration to an exact address
where the new mask is 0 and reinstalls it, the flow bypasses the uninstall
phase and calls setup_hwbp with enable set to true:

arch_manage_bp()->setup_hwbp()
    if (info->mask)
        amd_set_dr_addr_mask(enable ? info->mask : 0, slot);

Since info->mask evaluates to 0 for the new exact address breakpoint,
this condition skips calling amd_set_dr_addr_mask. This leaves the old
non-zero mask in the CPU MSR, which could cause the CPU to continue
monitoring the old, wider address range and potentially trigger spurious
hardware traps on memory accesses.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714182243.10687-1-wangjinchao600@gmail.com?part=3