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

[slipher]

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.

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


probe kernel.function("hw_breakpoint_pending").call {
	printf("hw_breakpoint_pending entered\n");
}

probe kernel.function("hw_breakpoint_pending").return {
	printf("hw_breakpoint_pending returned %d\n", $return);
}

// these are not called
probe kernel.function("watchpoint_handler") {
	printf("watchpoint_handler\n");
}
probe kernel.function("breakpoint_handler") {
	printf("breakpoint_handler\n");
}


Tested on a 7.0.12 kernel, the output is:

hw_breakpoint_pending entered
hw_breakpoint_pending returned 0
hw_breakpoint_pending entered
hw_breakpoint_pending returned 0
hw_breakpoint_pending entered
hw_breakpoint_pending returned 0
...