Re: [REGRESSION] 32-bit ARM's BKPT instruction no longer works

[Adding Nathan and Kees so we can figure out how best to deal with this]

On Sun, Jun 21, 2026 at 9:15 PM slipher <[email protected]> wrote:

> Consider the C program for 32-bit ARM architectures:
>
>
> int main() {
>         __asm__ __volatile__ ("BKPT");
>         return 0;
> }
>
> Expected behavior is that this raises SIGTRAP. Since Linux 6.10 this no
> longer happens; instead execution perpetually resumes at the same
> instruction, using 100% of CPU. It does not matter whether GDB is
> attached. I have tested with an armv7l CPU, but I imagine any other
> variants with the BKPT instruction would be equally affected.
>
> I believe the culprit to be commit
> c3f89986fde7bb9ccc86a901bf28e1f7d69fc3b3 "ARM: 9391/2: hw_breakpoint:
> Handle CFI breakpoints".  The commit defines the method-of-entry code 3
> as "ARM_ENTRY_CFI_BREAKPOINT", but this is the code used for any BKPT
> instruction - see
> https://developer.arm.com/documentation/ddi0379/a/Debug-Register-Reference/Control-and-status-registers/Debug-Status-and-Control-Register--DSCR-?lang=en
> "Method of Debug Entry (MOE), bits [5:2]". If the CFI option is disabled
> in the kernel config,  hw_breakpoint_pending() returns 0 indicating the
> breakpoint was handled, but takes no action. So breakpoints cannot be
> used by user-space code, regardless of how CONFIG_CFI is set. The blog
> post
> https://www.jwhitham.org/2015/04/the-mystery-of-fifteen-millisecond.html
> gives a nice overview of the control flow in older, working kernels.

Does simply reverting the patch solve the issue?

> The following Systemtap script can be used to demonstrate that the
> ARM_ENTRY_CFI_BREAKPOINT path is used, when running the above C program.

Yeah it's definitely that one causing it.

I sent the naive solution to it, and before anyone point it out: no it does
not allow custom breakpoints to be mixed with kernel CFI, but it
probably makes legacy systems work on newer kernels since they
probably don't select CFI.
https://lore.kernel.org/linux-arm-kernel/[email protected]/T/#u

I understand that this is not solving everything.

If it is under all circumstances unacceptable to be able to construct
a userspace which will change the user-facing behaviour of BKPT,
I think we need to revert CFI breakpoint handling, back put the patch,
disable CFI on ARM and wait for the compiler(s) to start behaving
differently on ARM.

CFI folks: any ideas on what we could do instead of BKPT
when we hit a CFI snag? Any ideas from other architectures?

Yours,
Linus Walleij