Re: [PATCH v8 08/13] KVM: s390: cmma: Fix dirty tracking when removing memslot

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [High] The CMMA dirty pages counter leaks when unmapped pages (holes) wit=
h `cmma_d =3D=3D 1` are deleted.
--

--- Patch [8]: [PATCH v8 08/13] KVM: s390: cmma: Fix dirty tracking when re=
moving memslot ---
commit 914169226ab516b51f60cbd45659598a2b39525d
Author: Claudio Imbrenda <[email protected]>

KVM: s390: cmma: Fix dirty tracking when removing memslot

This commit decrements the cmma-dirty counter when a memslot is removed
to ensure accurate dirty tracking during migration mode. It also
opportunistically adopts scope-based resource management for the
kvm_s390_mmu_cache.

> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index e5c5e9f61cb24..ba811f0673d10 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
[ ... ]
> @@ -5830,6 +5846,12 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
>  	}
> =20
>  	scoped_guard(write_lock, &kvm->mmu_lock) {
> +		if (kvm->arch.migration_mode && kvm->arch.use_cmma && old) {
> +			_dat_walk_gfn_range(old->base_gfn, old->base_gfn + old->npages,
> +					    kvm->arch.gmap->asce, &ops, DAT_WALK_IGN_HOLES,
> +					    &kvm->arch.cmma_dirty_pages);
> +		}
> +

[Severity: High]
Does this code leak the cmma_dirty_pages counter when unmapped pages (holes)
have cmma_d =3D=3D 1?

Because this pre-walk uses DAT_WALK_IGN_HOLES without DAT_WALK_ANY,
dat_pte_walk_range() will skip calling cmma_d_count_pte() for holes:

arch/s390/kvm/dat.c:dat_pte_walk_range() {
	if (pte_hole(READ_ONCE(table->ptes[idx]))) {
		if (!(w->flags & DAT_WALK_IGN_HOLES))
			return -EFAULT;
		if (!(w->flags & DAT_WALK_ANY))
			continue;
	}
	...
}

If a guest page was dirtied (setting cmma_d =3D 1 and incrementing the
counter), and then the host unmaps the page (e.g., via page reclaim
or MADV_DONTNEED), the PTE becomes a hole but the PGSTE retains
cmma_d =3D=3D 1.

When the memslot is removed, this pre-walk skips the hole, failing
to decrement cmma_dirty_pages. Then dat_delete_slot() walks the range
with DAT_WALK_ANY and clears cmma_d, causing the counter to permanently
leak.

If this counter never reaches 0, could it stall live migration by causing
userspace to infinite loop waiting for remaining dirty pages to drop to 0?

>  		switch (change) {
>  		case KVM_MR_DELETE:
>  			rc =3D dat_delete_slot(mc, kvm->arch.gmap->asce, old->base_gfn, old->=
npages);

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803124040.1264=
[email protected]?part=3D8