On Tue, Jul 18, 2017 at 02:45:04PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 18, 2017 at 09:22:38AM -0300, Marcelo Tosatti wrote:
> > > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > > > index 7e80f62..6375db8 100644
> > > > --- a/virt/kvm/kvm_main.c
> > > > +++ b/virt/kvm/kvm_main.c
> > > > @@ -613,6 +613,8 @@ static struct kvm *kvm_create_vm(unsigned long type)
> > > > return ERR_PTR(-ENOMEM);
> > > >
> > > > spin_lock_init(&kvm->mmu_lock);
> > > > +
> > > > + lockdep_set_novalidate_class(&kvm->mmu_lock.lock.wait_lock);
> > > > mmgrab(current->mm);
> > > > kvm->mm = current->mm;
> > > > kvm_eventfd_init(kvm);
> > >
> > > This doesn't make sense... It looks like a spin_lock_init() is missing,
> > > at which point it'll try and use the lock address itself and then bails
> > > because that is in dynamic memory.
> >
> > Do you see the spin_lock_init just above, after "return
> > PTR_ERR(-ENOMEM)"... That should take care of wait_lock i suppose.
>
> D'0h... so much for being 'awake'..
>
> > "struct kvm" (which contains the mmu_lock spinlock) is allocated with
> > kmalloc, can LOCKDEP handle spinlocks in kmalloc'ed memory?
>
> Yep, what _should_ happen is that we use a macro like:
>
> (I don't have an -RT tree handy atm)
>
> # define raw_spin_lock_init(lock) \
> do { \
> static struct lock_class_key __key; \
> \
> __raw_spin_lock_init((lock), #lock, &__key); \
> } while (0)
>
> Which defines a key per callsite. So while the lock itself is in dynamic
> memory, the key will be static.
One other interesting observation: the dump_stack() comes from the
acquire path, not from the _init() path, even though the _init() path
itself includes a check to ensure that the lock_class_key points to
static data. (__raw_spin_lock_init -> lockdep_init_map -> if (!static_obj(key)) BUG)
So, that would lead me to believe that if we got this far, at some point
lock->key _was_ pointing to static data, but now is not?
Julia
Caveat: I'm looking at v3.10.53-rt56; I guessed it was the closest
public stable tag to the undecipherable RHEL version.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: PGP signature
