From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758279AbdACMGc (ORCPT ); Tue, 3 Jan 2017 07:06:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33752 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752592AbdACMGX (ORCPT ); Tue, 3 Jan 2017 07:06:23 -0500 Subject: Re: [PATCH] KVM: ioapic: fix NULL deref ioapic->lock To: Wanpeng Li , Dmitry Vyukov References: <1483242289-12323-1-git-send-email-wanpeng.li@hotmail.com> Cc: Paolo Bonzini , LKML , KVM list , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Wanpeng Li From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Tue, 3 Jan 2017 13:06:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 03 Jan 2017 12:06:23 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> Thanks, this is beautiful enough. :) >>> >>> Hmm, the combination of 6c7caebc26c5 ("KVM: introduce >>> kvm->created_vcpus", 2016-06-16) and 4c5ea0a9cd02 ("locking/static_key: >>> Fix concurrent static_key_slow_inc()", 2016-06-24) should have fixed it >>> for good. >>> >>> Is the ENABLE_CAP necessary to reproduce? Then, the bug is simply that >>> the ENABLE_CAP should have failed without an irqchip (the >>> KVM_CREATE_IRQCHIP in turn must have failed with EINVAL). >> >> ENABLE_CAP is necessary to reproduce. > > Now I see what Paolo means, how about something like below: > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 51ccfe0..7ec22e2 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -3337,7 +3337,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct > kvm_vcpu *vcpu, > > switch (cap->cap) { > case KVM_CAP_HYPERV_SYNIC: > - return kvm_hv_activate_synic(vcpu); > + if (!irqchip_in_kernel(vcpu->kvm)) > + return -EINVAL; > + else You can simply drop the else and return directly. Can't really say if this is the right fix, my first thought was that a request has been set although it should never have been set for that VCPU. Maybe that is an effect of synic being activated (because synic code unconditionally later on sets the request). Fixing the cause of the request seems better than fixing up the result. -- David