SError Interrupt on CPU0, code 0xbf000000 makes kernel panic

[Joakim Tjernlund]

We have a custom SOC, CPU A53, that when an app accesses non existing address space reports:
# > devmem 0x20000000 w 0x1000 #this will open /dev/mem and write
 
[   37.570886] SError Interrupt on CPU0, code 0xbf000000 -- SError
[   37.571974] CPU: 0 PID: 72 Comm: devmem Not tainted 5.15.26-g18447c6fff6f-dirty #26
[   37.573150] Hardware name: infinera,xr (DT)
[   37.573599] pstate: 60000010 (nZCv q A32 LE aif -DIT -SSBS)
[   37.574705] pc : 000000000098775c
[   37.575063] lr : 0000000000986918
[   37.575392] sp : 00000000ffd140a8
[   37.575725] x12: 0000000000a36c10
[   37.576443] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000020
[   37.577872] x8 : 00000000ffd141c0 x7 : 00000000ffd14104 x6 : 0000000000986c9c
[   37.579278] x5 : 000000000000001f x4 : 0000000000000004 x3 : 0000000000a37020
[   37.580635] x2 : 0000000000000003 x1 : 0000000000001000 x0 : 0000000000000000
[   37.582164] Kernel panic - not syncing: Asynchronous SError Interrupt
[   37.582685] Kernel Offset: disabled
[   37.582932] CPU features: 0x00001001,20000842
[   37.583509] Memory Limit: none
[   37.630058] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

and the kernel panics. This is a surprise as I expected the app to just be killed bus a SIGBUS.
Is this what to expect?
I see that kernel looks for the RAS extension but we don't have that.

Can anything be done not to panic the kernel for such accesses?
Can one build a som sort of blacklisted address spaces which the MMU will block?

 Jocke