After Mark noticed that arm64 didn't have it, I checked armv7 and it
also doesn't have it.
Successfully tested on a Tinker-RK3288
OK?
Index: sys/arch/arm/arm/fault.c
===================================================================
RCS file: /home/cvs/openbsd/src/sys/arch/arm/arm/fault.c,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 fault.c
--- sys/arch/arm/arm/fault.c 14 Sep 2020 18:23:32 -0000 1.41
+++ sys/arch/arm/arm/fault.c 25 Sep 2020 06:21:48 -0000
@@ -331,6 +331,8 @@ data_abort_handler(trapframe_t *tf)
pcb->pcb_onfault = NULL;
KERNEL_LOCK();
error = uvm_fault(map, va, 0, ftype);
+ if (error == 0)
+ uvm_grow(p, va);
KERNEL_UNLOCK();
pcb->pcb_onfault = onfault;
@@ -588,6 +590,8 @@ prefetch_abort_handler(trapframe_t *tf)
KERNEL_LOCK();
error = uvm_fault(map, va, 0, PROT_READ | PROT_EXEC);
+ if (error == 0)
+ uvm_grow(p, va);
KERNEL_UNLOCK();
if (__predict_true(error == 0))
goto out;
On 2020 Sep 24 (Thu) at 23:16:08 +0200 (+0200), Mark Kettenis wrote:
:The call is missing from the trap handler, probably because I was
:looking at arm64 where it is missing as well. The result is that the
:stack size accounting will be wrong.
:
:In the diff below I only added the call to the "data" trap. That
:means that an "instruction" trap will not run the accounting code. Is
:that correct? The uvm_fault() call should never return success in
:that case unless the stack has been mapped executable...
:
--
Nature is by and large to be found out of doors, a location where, it
cannot be argued, there are never enough comfortable chairs.
-- Fran Leibowitz
