Re: [PATCH v2 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] Infinite loop on OOM in handle_sske() and handle_pfmf() due to ignored return value.
--

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

KVM: s390: vsie: Fix allocation of struct vsie_rmap

The allocation size for struct vsie_rmap in kvm_s390_mmu_cache_topup()
was wrong due to a copy-paste error. This patch fixes it by using the
correct size.

> diff --git a/arch/s390/kvm/dat.c b/arch/s390/kvm/dat.c
> index 4a41c0247ffa2..b3931e3592b52 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(sizeof(struct vsie_rmap), GFP_KERNEL_ACCOUNT);
>  		if (!o)
>  			return -ENOMEM;
>  		mc->rmaps[mc->n_rmaps] = o;

[Severity: High]
This isn't a bug introduced by this patch, but since we return -ENOMEM
here on allocation failure, are the callers handling this correctly?

Looking at handle_sske() in arch/s390/kvm/priv.c:

	while (start != end) {
		scoped_guard(read_lock, &vcpu->kvm->mmu_lock) {
			rc = dat_cond_set_storage_key(...);
		}
		if (rc > 1)
			return kvm_s390_inject_program_int(vcpu, PGM_ADDRESSING);
		if (rc == -ENOMEM) {
			kvm_s390_mmu_cache_topup(vcpu->arch.mc);
			continue;
		}
		if (rc < 0)
			return rc;
		start += PAGE_SIZE;
	}

If dat_cond_set_storage_key() fails with -ENOMEM, we call
kvm_s390_mmu_cache_topup() and then continue the loop. Since we ignore the
return value of kvm_s390_mmu_cache_topup(), if it also fails with -ENOMEM
(e.g., under severe memory pressure or with a pending SIGKILL), the loop
will restart with an empty cache.

Can this result in an endless retry loop causing a CPU soft-lockup?

The same pattern seems to exist in handle_pfmf() in the same file.

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