> Date: Fri, 25 Apr 2025 14:25:40 -0500
> From: joshua stein <[email protected]>
>
> My RK3128 came up with no ci_flush_bp assigned, because cpu0 never
> attached, because the reg values in the DTB were 0x000-0x003 rather
> than 0xf00-0xf03. This caused a "Fatal kernel mode prefetch abort"
> because it was trying to execute a null function pointer.
>
> It took me a while to figure out all of this so maybe we can panic
> instead of trying to execute a null function pointer to make it
> easier for the next person?
There must be better ways to do this that don't involve checking the
pointer on every page fault. Maybe in
arch/armv7/armv7/autocnf.c:cpu_configure()?
> diff --git sys/arch/arm/arm/fault.c sys/arch/arm/arm/fault.c
> index dfc0450467b..7a9b83cd7a3 100644
> --- sys/arch/arm/arm/fault.c
> +++ sys/arch/arm/arm/fault.c
> @@ -215,8 +215,12 @@ data_abort_handler(trapframe_t *tf)
> * Flush BP cache on processors that are vulnerable to branch
> * target injection attacks if access is outside user space.
> */
> - if (va < VM_MIN_ADDRESS || va >= VM_MAX_ADDRESS)
> + if (va < VM_MIN_ADDRESS || va >= VM_MAX_ADDRESS) {
> + if (__predict_false(curcpu()-> ci_flush_bp == NULL))
> + panic("%s: no curcpu ci_flush_bp\n", __func__);
> +
> curcpu()->ci_flush_bp();
> + }
>
> if (user) {
> if (!uvm_map_inentry(p, &p->p_spinentry, PROC_STACK(p),
>
>
