Re: [PATCH 13/60] kvm: Add read accessors for kvm_vcpu scheduling state

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] LoongArch's `kvm_vcpu_set_pv_preempted()` calls `unsafe_put_user()` in an atomic context without disabling page faults, which can lead to a 'scheduling while atomic' panic.
--

commit 3087f4d4153f32bcbd70753c3a4b6b003d538bfa
Author: Joerg Roedel <joerg.roedel@amd.com>

kvm: Add read accessors for kvm_vcpu scheduling state

Introduce accessor functions for the scheduling state in struct
kvm_vcpu to make it easier to move these fields to struct
kvm_vcpu_common.

[ ... ]

> diff --git a/arch/loongarch/kvm/vcpu.c b/arch/loongarch/kvm/vcpu.c
> index e28084c49e682..bde8b68b82738 100644
> --- a/arch/loongarch/kvm/vcpu.c
> +++ b/arch/loongarch/kvm/vcpu.c
> @@ -1847,7 +1847,8 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>  	int cpu, idx;
>  	unsigned long flags;
>  
> -	if (vcpu->preempted && kvm_guest_has_pv_feature(vcpu, KVM_FEATURE_PREEMPT)) {
> +	if (kvm_vcpu_preempted(vcpu) &&
> +	    kvm_guest_has_pv_feature(vcpu, KVM_FEATURE_PREEMPT)) {
>  		/*
>  		 * Take the srcu lock as memslots will be accessed to check
>  		 * the gfn cache generation against the memslots generation.
>  		 */
>  		idx = srcu_read_lock(&vcpu->kvm->srcu);
>  		kvm_vcpu_set_pv_preempted(vcpu);

[Severity: High]
This is a pre-existing issue, but this path appears to call unsafe_put_user()
in an atomic context without disabling page faults, which can lead to a
'scheduling while atomic' panic.

kvm_arch_vcpu_put() is called with preemption disabled (via vcpu_put() or
the scheduler's kvm_sched_out() preempt notifier). From this atomic context,
it calls kvm_vcpu_set_pv_preempted(), which does the following:

arch/loongarch/kvm/vcpu.c:kvm_vcpu_set_pv_preempted() {
    ...
    st = (struct kvm_steal_time __user *)ghc->hva;
    unsafe_put_user(KVM_VCPU_PREEMPTED, &st->preempted, out);
    ...
}

Because unsafe_put_user() does not implicitly disable page faults (unlike
x86's copy_to_user_nofault()), a page fault on a valid but swapped-out
userspace page will cause the kernel's fault handler to proceed to
handle_mm_fault().

Since handle_mm_fault() can sleep, could this trigger a 'scheduling while
atomic' BUG and crash the system under memory pressure?

Additionally, is unsafe_put_user() improperly used here without the required
user_access_begin() and user_access_end() wrappers?

>  		srcu_read_unlock(&vcpu->kvm->srcu, idx);
>  	}

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608144252.351443-1-joro@8bytes.org?part=13