Message-ID: <8adb9dcb-621a-0392-9ccd-0117345636ec@ghiti.fr>
Date:   Fri, 24 Feb 2023 13:47:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [PATCH] RISC-V: mm: Support huge page in vmalloc_fault()
Content-Language: en-US
To:     Dylan Jhong <dylan@andestech.com>, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org
Cc:     liushixin2@huawei.com, x5710999x@gmail.com, bjorn@rivosinc.com,
        abrestic@rivosinc.com, peterx@redhat.com, hanchuanhua@oppo.com,
        apopple@nvidia.com, hca@linux.ibm.com, aou@eecs.berkeley.edu,
        palmer@dabbelt.com, paul.walmsley@sifive.com, tim609@andestech.com,
        peterlin@andestech.com, ycliang@andestech.com
References: <20230224104001.2743135-1-dylan@andestech.com>
From:   Alexandre Ghiti <alex@ghiti.fr>
In-Reply-To: <20230224104001.2743135-1-dylan@andestech.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Dylan,

On 2/24/23 11:40, Dylan Jhong wrote:
> RISC-V supports ioremap() with huge page (pud/pmd) mapping, but
> vmalloc_fault() assumes that the vmalloc range is limited to pte
> mappings. Add huge page support to complete the vmalloc_fault()
> function.
>
> Fixes: 310f541a027b ("riscv: Enable HAVE_ARCH_HUGE_VMAP for 64BIT")
>
> Signed-off-by: Dylan Jhong <dylan@andestech.com>
> ---
>   arch/riscv/mm/fault.c | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> index eb0774d9c03b..4b9953b47d81 100644
> --- a/arch/riscv/mm/fault.c
> +++ b/arch/riscv/mm/fault.c
> @@ -143,6 +143,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
>   		no_context(regs, addr);
>   		return;
>   	}
> +	if (pud_leaf(*pud_k))
> +		goto flush_tlb;
>   
>   	/*
>   	 * Since the vmalloc area is global, it is unnecessary
> @@ -153,6 +155,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
>   		no_context(regs, addr);
>   		return;
>   	}
> +	if (pmd_leaf(*pmd_k))
> +		goto flush_tlb;
>   
>   	/*
>   	 * Make sure the actual PTE exists as well to
> @@ -172,6 +176,7 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
>   	 * ordering constraint, not a cache flush; it is
>   	 * necessary even after writing invalid entries.
>   	 */
> +flush_tlb:
>   	local_flush_tlb_page(addr);
>   }
>   


This looks good to me, you can add:

Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>

One question: how did you encounter this bug?

Thanks,

Alex