From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B638DCD11C2 for ; Wed, 10 Apr 2024 17:28:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21C156B0087; Wed, 10 Apr 2024 13:28:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CBE06B0089; Wed, 10 Apr 2024 13:28:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E1E56B008C; Wed, 10 Apr 2024 13:28:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E39976B0087 for ; Wed, 10 Apr 2024 13:28:46 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A84E4A08AD for ; Wed, 10 Apr 2024 17:28:46 +0000 (UTC) X-FDA: 81994307052.02.5909360 Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by imf13.hostedemail.com (Postfix) with ESMTP id CB4A12001D for ; Wed, 10 Apr 2024 17:28:43 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of alex@ghiti.fr designates 217.70.183.198 as permitted sender) smtp.mailfrom=alex@ghiti.fr ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712770124; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OT9/J1EOceOBL8jteJqfJLmxapcIkBOv4H+4+OenyC8=; b=KQj9E4hpayW2tluR4KZyT/0M8H3G0mfxB7VmnVTjQAGUB4rNVJ/3cMXfFz0VOAhD/yPOmH bHrEpxHzuQpHiYzi9eKeM18ftmAOgKZjYxxyAFTmAetHhz62gqnZJGrq+kwfmz9MobRd9z 2g2vE5gnOF62xuMvyQxnjb8/OkY7SMw= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of alex@ghiti.fr designates 217.70.183.198 as permitted sender) smtp.mailfrom=alex@ghiti.fr ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712770124; a=rsa-sha256; cv=none; b=OUjNEjYzfpZXnDS5F+eIkMI35mRS8E2uBRUmKuP+uJXbDzTjbU9dgq9vk1C5NzG6Z1Xv9N EQ8H3VqbEHUGsoM68mnDQ2pCiwynBJ+D1RxhV6UlKHB5J4asioZQujSx9tnv1dt79RHD0o qacVYt6URYkiW28Z8qBgDoefdh9sGf8= Received: by mail.gandi.net (Postfix) with ESMTPSA id 376E7C0004; Wed, 10 Apr 2024 17:28:36 +0000 (UTC) Message-ID: <3493a2f4-9cae-4773-a6a1-2eeb2d23f0c8@ghiti.fr> Date: Wed, 10 Apr 2024 19:28:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/7] riscv: mm: accelerate pagefault when badaccess Content-Language: en-US To: Kefeng Wang , akpm@linux-foundation.org Cc: Russell King , Catalin Marinas , Will Deacon , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexander Gordeev , Gerald Schaefer , Dave Hansen , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, surenb@google.com, linux-mm@kvack.org References: <20240403083805.1818160-1-wangkefeng.wang@huawei.com> <20240403083805.1818160-6-wangkefeng.wang@huawei.com> <8fe1a53f-f031-4423-97e1-28d93d0cd59e@ghiti.fr> From: Alexandre Ghiti In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-GND-Sasl: alex@ghiti.fr X-Rspamd-Queue-Id: CB4A12001D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: o6zyf559ccff5w5r1psb7yj6j7irhmgs X-HE-Tag: 1712770123-968248 X-HE-Meta: U2FsdGVkX18gsd60dr4nzZtbgjPYM79ys7Udmt3f9yeGHTeQgUKRPI5fQsoVqBjQYGaHz4ghMyAoK1wGScb1yt9Gb8nURvuc2yw8eT46fdKnsoAS5lrpEKi+gT1M0ph8UwXmlCU7turXOp2mfW5YmXcU0k3l+SNsAv4B7WjQPyzhrpwRwNHAdBxVp2lVIYxmZEKGjmK/upst4aqRsf1cJgmm6dsP6Esbrks9wq7TbiahWv8jtfKoBqYcMQKWHkSWyj2WcEGX31O++Ti0DkBQszcpttRxeuub761z4oU/cUSdxcp1tL4fJdSmR7z7oIKM0XcVC3Tp3yPxb/TRJI4pUIQO2S63+9Apu3oN8vZcZdCXB35h78Cy9cln5diSAdStIQxAW6IJ50OjN6AbxiguFhM3CyT5oVdV698uiI793QlfGZhmGjWegamnUd73mvhxauJUzmZ5ZgQDLd2MjUKus8F8zKmF9KWSahuQ1COE0CWxTJ4seIbj0VwPuqnTRoNQt96n6LOp9xRbeIuV+2njqv6MMhkryhrkCFrhu2ts095t3ojcaPmdpqWSx9m1Ylp6ZeFcWSYLVfqR7WO3iGsJqz3lhfOhuWoh7AtSRAW2+Ff77l/pH/VglWwnbF/MGBPIWu4qOPxeOwZLC591unfPwlieCGb4FfGgrydFMuz4Po3RGUPTdIr1kcOZmlBgTL0UUw+YlXwX8tLA1wc07bBEOFBQn/OkbO5d0Xe3hGnvrYDnjB3WUO5CPoo/ocgC5PGZr4AXnELTeT0NKKsrQcSKDNylBtSr+rsXKQIIcDnXDCIDF6gQuVqxel7B0s8xgvxejHMJwK348KDKHMHxQedhmY0vWmrGL4/dDsmynYidy0agrTRbchMo8PHMuFPXJ8EK78KQGiVVBBfeX6kuJSMPzoMMPOj0pad75gdL5C5+NawozbPh4bpke3Nw41kRbBxaoe0RshwJ6lP+NfbEdED UdnIgcVl FLGZW7tBhwYKwzMQcZxqQWppmUg2Kwu/CktgPiR9B0BO56AftTmRlzzB/xJsbUpzOuwFPCozEH/P5wfQLOusTShxT5/LJjzD7e9+ZNiPJJWpY8U7pEEK7peae1nQn3zH9g1biFqAhweHKCc1Z/VHrOnPQpXCw7qHH1gYWdxEZiYe6xGBgJQqetgsFh2ie7mWXXP2cwmj8DMR9Jaahlx9Jndp1+w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 10/04/2024 10:07, Kefeng Wang wrote: > > > On 2024/4/10 15:32, Alexandre Ghiti wrote: >> 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 >>> Signed-off-by: Kefeng Wang >>> --- >>>   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. > > Oh, I see, it is exception causes on riscv, so it should be > > diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c > index b3fcf7d67efb..5224f3733802 100644 > --- a/arch/riscv/mm/fault.c > +++ b/arch/riscv/mm/fault.c > @@ -293,8 +293,8 @@ void handle_page_fault(struct pt_regs *regs) >         if (unlikely(access_error(cause, vma))) { >                 vma_end_read(vma); >                 count_vm_vma_lock_event(VMA_LOCK_SUCCESS); > -               tsk->thread.bad_cause = SEGV_ACCERR; > -               bad_area_nosemaphore(regs, code, addr); > +               tsk->thread.bad_cause = cause; > +               bad_area_nosemaphore(regs, SEGV_ACCERR, addr); >                 return; >         } > > Hi Alex, could you help to check it? > > Hi Andrew, please help to squash it after Alex ack it. > > Thanks both. So I have just tested Kefeng's fixup on my usual CI and with a simple program that triggers such bad access, everything went fine so with the fixup applied: Reviewed-by: Alexandre Ghiti Tested-by: Alexandre Ghiti Thanks, Alex > > >> >> Thanks, >> >> Alex >> >> >>> +        bad_area_nosemaphore(regs, code, addr); >>> +        return; >>>       } >>>       fault = handle_mm_fault(vma, addr, flags | >>> FAULT_FLAG_VMA_LOCK, regs);