Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 24 Mar 2023 16:13:37 -0700 | Subject | Re: [PATCH v3] KVM: VMX: fix lockdep warning on posted intr wakeup | From | Sean Christopherson <> |
| |
On Mon, Mar 13, 2023, Yan Zhao wrote: > The lock ordering after this patch are: > - &p->pi_lock --> &rq->__lock --> > &per_cpu(wakeup_vcpus_on_cpu_lock_out, cpu) > - &per_cpu(wakeup_vcpus_on_cpu_lock_in, cpu) --> > &per_cpu(wakeup_vcpus_on_cpu_lock_out, cpu) > - &per_cpu(wakeup_vcpus_on_cpu_lock_in, cpu) --> &p->pi_lock > > Currently, &rq->__lock is not held in "path sched_in". > However, if in future "path sched_in" takes &p->pi_lock or &rq->__lock, > lockdep is able to detect and warn in that case. > > Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> > [sean: path sched_out and path irq does not race, path sched_in does not > take &rq->__lock]
But there's no actual deadlock, right? I have zero interest in fixing a lockdep false positive by making functional changes to KVM. I am definitely open to making changes to somehow let lockdep know what's going on, but complicating KVM's actual functionality is too much.
| ![\](/images/icornerr.gif) |