All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: sashiko-reviews@lists.linux.dev, Paolo Bonzini <pbonzini@redhat.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>
Subject: Re: [PATCH v2 6/7] KVM: s390: Take srcu when importing watchpoint data
Date: Wed, 5 Aug 2026 10:21:41 +0200	[thread overview]
Message-ID: <dabd9090-e1b6-4695-8782-47b6c8e37a73@linux.ibm.com> (raw)
In-Reply-To: <20260804184024.B9A961F000E9@smtp.kernel.org>

Am 04.08.26 um 20:40 schrieb sashiko-bot@kernel.org:
> 
> [Severity: High]
> Could holding the SRCU read lock across this call introduce a userfaultfd
> deadlock?
> 
> Inside kvm_s390_import_bp_data(), the very first operation is:
> 
> arch/s390/kvm/guestdbg.c:kvm_s390_import_bp_data() {
>      ...
>      bp_data = memdup_array_user(dbg->arch.hw_bp, dbg->arch.nr_hw_bp,
>                                  sizeof(*bp_data));
>      ...
> }
> 
> If user space maps this array using userfaultfd, the VCPU thread will block
> in copy_from_user() while holding the kvm->srcu read lock. If the user space
> userfaultfd handler attempts to execute a VM-wide KVM ioctl that modifies
> memslots (such as KVM_SET_USER_MEMORY_REGION), that ioctl will call
> synchronize_srcu(&kvm->srcu). The VCPU thread would wait for the page fault
> to be resolved, and the userfaultfd handler would wait for the SRCU lock to
> be released.


Now I am puzzled. Sashiko basically asked for srcu protection for the guest access
in the same review series. But I want to followup nevertheless.


There are other places in KVM code which do access guest memory under the srcu.

1.
KVM_SET_NESTED_STATE — arch/x86/kvm/x86.c
               idx = srcu_read_lock(&vcpu->kvm->srcu);
               r = kvm_x86_ops.nested_ops->set_state(vcpu, user_kvm_nested_state, &kvm_state);
               srcu_read_unlock(&vcpu->kvm->srcu, idx);
with  vmx_set_nested_state() then copying  the vmcs12 from user


2.
KVM_GET_MSRS / KVM_SET_MSRS — arch/x86/kvm/x86.c

       case KVM_SET_MSRS: {
               int idx = srcu_read_lock(&vcpu->kvm->srcu);
               r = msr_io(vcpu, argp, do_set_msr, 0);
               srcu_read_unlock(&vcpu->kvm->srcu, idx);
               break;
       }
argp goes in as a raw void __user *, and msr_io() does both user copies inside that section:

       if (copy_from_user(&msrs, user_msrs, sizeof(msrs)))


3.
KVM_S390_MEM_OP
kvm_s390_vm_mem_op_abs() has
         scoped_guard(srcu, &kvm->srcu) {
[...]
                 if (acc_mode == GACC_STORE && copy_from_user(tmpbuf, uaddr, mop->size))
                         return -EFAULT;


4.
KVM_PRE_FAULT_MEMORY generic KVM holds srcu across a loop of kvm_arch_vcpu_pre_fault_memory() calls that fault in guest memory,

5.
and last but not least,isnt vcpu_run also holding kvm->srcu when handling page faults?

In the end the cycle seems userspace constructed. It deadlocks only if its own uffd handler
is made to depend on a vcpu blocked on that same handler.The faulting side waits in
TASK_KILLABLE (mm/userfaultfd.c:2673) — SIGKILL to the process releases the srcu section
and lets the other thread finish.  So we can get out of it.


So I think this finding is wrong. Paolo?

  reply	other threads:[~2026-08-05  8:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 16:24 [PATCH v2 0/7] KVM: s390: more fixes Christian Borntraeger
2026-08-04 16:24 ` [PATCH v2 1/7] KVM: s390: Remove user triggerable WARN_ON Christian Borntraeger
2026-08-04 16:33   ` sashiko-bot
2026-08-04 17:47   ` Douglas Freimuth
2026-08-04 16:24 ` [PATCH v2 2/7] KVM: s390: Zero initialize data structures for inject_pfault_token Christian Borntraeger
2026-08-04 17:05   ` sashiko-bot
2026-08-04 16:24 ` [PATCH v2 3/7] KVM: s390: Zero initialize irq in reinject_machine_check Christian Borntraeger
2026-08-04 17:18   ` Matthew Rosato
2026-08-04 17:20   ` sashiko-bot
2026-08-04 16:24 ` [PATCH v2 4/7] KVM: s390: Fix memory leak in guest debug handling Christian Borntraeger
2026-08-04 18:00   ` sashiko-bot
2026-08-04 16:24 ` [PATCH v2 5/7] KVM: s390: Fix old_data leak in guest debug error path Christian Borntraeger
2026-08-04 17:19   ` Matthew Rosato
2026-08-04 18:19   ` sashiko-bot
2026-08-04 16:24 ` [PATCH v2 6/7] KVM: s390: Take srcu when importing watchpoint data Christian Borntraeger
2026-08-04 18:40   ` sashiko-bot
2026-08-05  8:21     ` Christian Borntraeger [this message]
2026-08-04 16:24 ` [PATCH v2 7/7] KVM: s390: Free guest debug data on vcpu destroy Christian Borntraeger
2026-08-04 18:47   ` sashiko-bot
2026-08-04 20:03   ` Matthew Rosato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dabd9090-e1b6-4695-8782-47b6c8e37a73@linux.ibm.com \
    --to=borntraeger@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.