Re: [PATCH v3 3/5] KVM: s390: vsie: Fix allocation of struct vsie_rmap

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Unhandled memory allocation failures in `handle_sske()` and `handle_pfmf()` lead to an unkillable infinite kernel loop.
--

commit abe0e652d367e02d61446edc9873e41898b993e0
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>

KVM: s390: vsie: Fix allocation of struct vsie_rmap

This commit fixes a copy-paste error in the allocation size for struct
vsie_rmap in kvm_s390_mmu_cache_topup().

> diff --git a/arch/s390/kvm/dat.c b/arch/s390/kvm/dat.c
> index 4a41c0247ffa2..a4fe664f65ee1 100644
> --- a/arch/s390/kvm/dat.c
> +++ b/arch/s390/kvm/dat.c
> @@ -45,7 +45,7 @@ int kvm_s390_mmu_cache_topup(struct kvm_s390_mmu_cache *mc)
>  		mc->pts[mc->n_pts] = o;
>  	}
>  	for ( ; mc->n_rmaps < KVM_S390_MMU_CACHE_N_RMAPS; mc->n_rmaps++) {
> -		o = kzalloc_obj(*mc->rmaps[0], GFP_KERNEL_ACCOUNT);
> +		o = kzalloc_obj(struct vsie_rmap, GFP_KERNEL_ACCOUNT);
>  		if (!o)
>  			return -ENOMEM;

[Severity: High]
This is a pre-existing issue, but I noticed some callers of
kvm_s390_mmu_cache_topup() do not check its return value.

For example, looking at handle_sske() in arch/s390/kvm/priv.c:

    if (rc == -ENOMEM) {
        kvm_s390_mmu_cache_topup(vcpu->arch.mc);
        continue;
    }

If kvm_s390_mmu_cache_topup() returns -ENOMEM due to memcg limits, does
this create an infinite loop since it immediately retries with an empty
cache and fails again?

The same pattern appears in handle_pfmf() in arch/s390/kvm/priv.c:

    if (rc == -ENOMEM) {
        kvm_s390_mmu_cache_topup(vcpu->arch.mc);
        continue;
    }

Without a fatal_signal_pending() check in these loops, could this prevent
the host OOM killer from terminating the VM process?

>  		mc->rmaps[mc->n_rmaps] = o;
>  	}
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611104850.110313-1-imbrenda@linux.ibm.com?part=3