On Fri, 2025-03-21 at 12:49 +0100, Paolo Bonzini wrote: > On Wed, Mar 19, 2025 at 5:17 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > Yan posted a patch to fudge around the issue[*], I strongly objected (and still > > object) to making a functional and confusing code change to fudge around a lockdep > > false positive. > > In that thread I had made another suggestion, which Yan also tried, > which was to use subclasses: > > - in the sched_out path, which cannot race with the others: > raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu), 1); > > - in the irq and sched_in paths, which can race with each other: > raw_spin_lock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu)); Hi, I also have no objections to this. As it was said in the original discussion, that can make lockdep miss a bug, but so can the Sean's solution. I don't think there is a way to both fix the warning and not degrade the check in some way but since the check disables lockdep, either of these two fixes is much better that what we have now. So what should I do to fix this? Can I assume that one of you post a patch to fix this, or should I post a patch with one of these solutions? (I want to close a ticket that I have :) ) Best regards, Maxim Levitsky > > Paolo >
