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@xxxxxxxxx> > [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.
