From mboxrd@z Thu Jan  1 00:00:00 1970
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Subject: Re: [PATCH v3 0/2] kvm: x86: hyperv: fix userspace interaction flaws
Date: Thu, 13 Jul 2017 20:52:38 +0200
Message-ID: <20170713185238.GG28875@potion>
References: <20170622135102.22487-1-rkagan@virtuozzo.com>
 <1119f913-149c-26dc-4078-ffe77f716895@redhat.com>
 <20170713152955.GA3916@rkaganb.sw.ru>
 <20170713154558.GF28875@potion>
 <20170713163828.GG3442@potion>
 <20170713164128.GH3442@potion>
 <20170713181549.GA10777@rkaganb.sw.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
To: Roman Kagan <rkagan@virtuozzo.com>,
        Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org,
        Evgeny Yakovlev <eyakovlev@virtuozzo.com>,
        "Denis V . Lunev" <den@openvz.org>,
        Eduardo Habkost <ehabkost@redhat.com>,
        Igor Mammedov <imammedo@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:42256 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752543AbdGMSwt (ORCPT <rfc822;kvm@vger.kernel.org>);
        Thu, 13 Jul 2017 14:52:49 -0400
Content-Disposition: inline
In-Reply-To: <20170713181549.GA10777@rkaganb.sw.ru>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

2017-07-13 21:15+0300, Roman Kagan:
> On Thu, Jul 13, 2017 at 06:41:29PM +0200, Radim Krčmář wrote:
> > 2017-07-13 18:38+0200, Radim Krčmář:
> > > 2017-07-13 17:45+0200, Radim Krčmář:
> > > > 2017-07-13 18:29+0300, Roman Kagan:
> > > > > On Fri, Jun 23, 2017 at 12:54:25PM +0200, Paolo Bonzini wrote:
> > > > > > On 22/06/2017 15:51, Roman Kagan wrote:
> > > > > > Looks good, thanks.
> > > > > 
> > > > > Are there still any problems with this series?
> > > > > I don't see it in kvm queue, so presumably it wasn't accepted...
> > > > 
> > > > No, the problem was on my side.  Queing it for the end of this merge
> > > > window.  Thanks for the ping.
> > > 
> > > And took it out after hitting a bug:  we're asking for the VP_INDEX before the
> > > VCPU is in kvm->vcpus[], but the index is its position in that array.
> > > I think we can just use kvm->online_vcpus instead of kvm_vcpu_get_idx().
> > 
> > Ugh, definitely no, we're not under kvm->lock there.
> > Assigning the VP_INDEX in kvm_arch_vcpu_postcreate() would be doable,
> > but adding a new callback before exposing the VCPU fd is probably safer.
> 
> But kvm_arch_vcpu_postcreate() *is* the last thing that's called before
> returning the VCPU fd.  Isn't it the right place to do it?  Or do you
> mean a dedicated kvm_hv_vcpu_postcreate() call rather than open-coding
> it there?

It is, I just didn't want to guarantee that nothing bad can happen

 1) after create_vcpu_fd() -- another thread can already access the fd
    (getting its number just takes some guess-work)

 2) after atomic_inc(&kvm->online_vcpus) -- the VCPU's vp_index is still
    invalid 0, but someone (get_vcpu_by_vpidx()) might look at it

I'd prefer to reuse kvm_arch_vcpu_postcreate() if it looks ok to you.
(Adding a new call only after all sane solutions have failed.)

> Roman,
> fixing his scripts not to ignore errors from insmod when smoke-testing
> kernel modules (facepalm)...

:) tests for tests for ...