Re: [PATCH v5 4/5] RISC-V: KVM: Split huge pages during KVM_CLEAR_DIRTY_LOG

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Dropping `mmu_lock` inside `mmu_split_huge_pages` before flushing the TLB for write-protected pages breaks caller atomicity and allows untracked guest writes.
- [Medium] Splitting huge pages after write-protecting them causes all resulting 4KB pages to inherit read-only permissions, unintentionally write-protecting memory outside the requested mask.
--

--- Patch [4]: [PATCH v5 4/5] RISC-V: KVM: Split huge pages during KVM_CLEAR_DIRTY_LOG ---
commit 7f655ea60f5c58e768006af9329d81bc92d97d34
Author: Wang Yechao <wang.yechao255@zte.com.cn>

RISC-V: KVM: Split huge pages during KVM_CLEAR_DIRTY_LOG

Split huge pages on the range specified using KVM_CLEAR_DIRTY_LOG.
And do not split when enabling dirty logging if KVM_DIRTY_LOG_INITIALLY_SET
is set.

> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index 5a93cffa9ad7f..722637a85bdf9 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c
> @@ -168,6 +168,9 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
>  
>  	kvm_riscv_gstage_wp_range(&gstage, start, end);
>  
> +	if (kvm_dirty_log_manual_protect_and_init_set(kvm))
> +		mmu_split_huge_pages(&gstage, start, end);

[Severity: Medium]
Since mmu_split_huge_pages() is called after kvm_riscv_gstage_wp_range(),
won't the newly split 4KB child PTEs inherit the read-only permission from
the huge PTE?

If KVM_CLEAR_DIRTY_LOG targets only a subset of pages in a 2MB huge page,
this would unintentionally write-protect memory outside the requested mask
and cause spurious page faults.

Could this be resolved by performing the split before write-protecting?

[Severity: High]
Does dropping the mmu_lock inside mmu_split_huge_pages() before the TLB is
flushed break caller atomicity and allow untracked guest writes?

Looking at arch/riscv/kvm/mmu.c:mmu_split_huge_pages():

	while (addr < end) {
		if (need_topup_split_caches_or_resched(kvm, count)) {
			...
			write_unlock(&kvm->mmu_lock);
			cond_resched();

If kvm_riscv_gstage_wp_range() write-protects the PTE, and then
mmu_split_huge_pages() drops kvm->mmu_lock, the hardware TLB is still
writable because the caller hasn't flushed the TLB yet.

Can concurrent guest writes succeed without a VM-exit during this window,
bypassing the cleared software dirty bitmap and violating the dirty logging
contract?

> +
>  	/*
>  	 * remote TLB flush is not needed here since callers of
>  	 * kvm_arch_mmu_enable_log_dirty_pt_masked() already do it.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731091215.1549430-1-wang.yechao255@zte.com.cn?part=4