Re: [PATCH v4 2/5] KVM: riscv: Avoid THP adjustment for existing 4K G-stage leaves

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete bug fix allows an infinite page fault loop when handling THP-backed memory.
--

--- Patch [2]: [PATCH v4 2/5] KVM: riscv: Avoid THP adjustment for existing 4K G-stage leaves ---
commit 6582fbd6641ea5762d156dac1847e91f07decbd7
Author: Jinyu Tang <jinyu.tang@linux.dev>

    KVM: riscv: Avoid THP adjustment for existing 4K G-stage leaves

This commit updates transparent_hugepage_adjust() to check if the original
fault GPA already has a 4K G-stage leaf. If so, it skips THP adjustment and
handles the fault at PAGE_SIZE granularity.

> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index bfd6168ebe308..2fabcd4099919 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c
[ ... ]
> @@ -500,10 +500,21 @@ static int get_hva_mapping_size(struct kvm *kvm,
>  
>  static unsigned long transparent_hugepage_adjust(struct kvm *kvm,
>  						 struct kvm_memory_slot *memslot,
> +						 struct kvm_gstage *gstage,
>  						 unsigned long hva,
>  						 kvm_pfn_t *hfnp, gpa_t *gpa)
>  {
>  	kvm_pfn_t hfn = *hfnp;
> +	u32 ptep_level;
> +	pte_t *ptep;
> +
> +	/*
> +	 * Keep the existing split G-stage leaf and update the original
> +	 * faulting 4K page in the vCPU fault path.
> +	 */
> +	if (kvm_riscv_gstage_get_leaf(gstage, *gpa, &ptep, &ptep_level) &&
> +	    !ptep_level)
> +		return PAGE_SIZE;

[Severity: High]
This is a pre-existing issue, but does this fully prevent the infinite page
fault loop when handling THP-backed memory?

This check only validates the unaligned faulting GPA. If the faulting GPA is
unmapped, it proceeds to align the GPA to the PMD base. However, if the PMD
base itself already has a 4K leaf (e.g., from a prior access while dirty
logging was enabled), transparent_hugepage_adjust() will still return
PMD_SIZE.

When called with the aligned GPA (the PMD base), kvm_riscv_gstage_map_page()
will find the 4K leaf at the PMD base:

arch/riscv/kvm/gstage.c:kvm_riscv_gstage_map_page() {
    ...
		} else if (ALIGN_DOWN(PFN_PHYS(pte_pfn(ptep_get(ptep))), page_size) == hpa) {
			kvm_riscv_gstage_update_pte_prot(gstage, ptep_level, gpa, ptep, prot);
			return 0;
		}
    ...
}

It updates the protection bits of the PMD base leaf and returns success
without mapping the original faulting GPA. Could this leave the originally
faulting GPA unmapped, causing the vCPU to hang in an infinite page fault
loop?

>  
>  	/*
>  	 * Make sure the adjustment is done only for THP pages. Also make

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260815095548.860018-1-jinyu.tang@linux.dev?part=2