[PATCH v2 5/7] riscv: mm: accelerate pagefault when badaccess
Alexandre Ghiti
alex at ghiti.fr
Wed Apr 10 00:32:51 PDT 2024
Hi Kefeng,
On 03/04/2024 10:38, Kefeng Wang wrote:
> The access_error() of vma already checked under per-VMA lock, if it
> is a bad access, directly handle error, no need to retry with mmap_lock
> again. Since the page faut is handled under per-VMA lock, count it as
> a vma lock event with VMA_LOCK_SUCCESS.
>
> Reviewed-by: Suren Baghdasaryan <surenb at google.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang at huawei.com>
> ---
> arch/riscv/mm/fault.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> index 3ba1d4dde5dd..b3fcf7d67efb 100644
> --- a/arch/riscv/mm/fault.c
> +++ b/arch/riscv/mm/fault.c
> @@ -292,7 +292,10 @@ void handle_page_fault(struct pt_regs *regs)
>
> if (unlikely(access_error(cause, vma))) {
> vma_end_read(vma);
> - goto lock_mmap;
> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
> + tsk->thread.bad_cause = SEGV_ACCERR;
I think we should use the cause variable here instead of SEGV_ACCERR, as
bad_cause is a riscv internal status which describes the real fault that
happened.
Thanks,
Alex
> + bad_area_nosemaphore(regs, code, addr);
> + return;
> }
>
> fault = handle_mm_fault(vma, addr, flags | FAULT_FLAG_VMA_LOCK, regs);
More information about the linux-riscv
mailing list