Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1629348ybi; Wed, 17 Jul 2019 19:04:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqy0ZtxJQ66awhDnMCP8PdW3DakyCj6GXFLnWKkRxP2WOJk9zp6QFujlcZI+ctzZwHXPOckS X-Received: by 2002:a17:90a:2008:: with SMTP id n8mr47334841pjc.4.1563415465707; Wed, 17 Jul 2019 19:04:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563415465; cv=none; d=google.com; s=arc-20160816; b=S+hnMYvXcrFciA2cHj8clVz4UfQnOkaq917krUVZG6UHorpPQsJjK1m8lQp1UPa30g 6stC7bAAFOjnjjrSOO7hGAdQWyivW44QVnu0VlOikuWfNbhJbxJVDNs7Y+xxKptkXLkB fgnk4H+r/vbgKstTa7c5ERWYNw+H04FXeAJYtMVthjqKuMpIhh0nAso3eYoZYRjwTEMX fkAOXgDsNnwMh+pXkltlZ2U6NIm176H5wkR1sLGAz2z38GNQ8vj4ZhZ7DRhl29VmjgRS 0AbIJj5cyVwkDDCOWphHqKNAqUHYTJTtALwDEsUNApAYJguILmijpZczuPxsDTBAAoyu hAMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=oj2S/l5PLOffz9ZVHpI4zU3t+jxcb9XdkLBxfQlUs7g=; b=iGw4mBz2tR4QziUeXd7wh6FYUpMQ+kDD2Bu7Jep2OxtD2ybG7ZHkTzLSt1nk63+VgH mks6Bu+mIyi6NCcY3KogVdhVgqEvdKzle5u1HI9kNdqhbAOO4kwgUgM9HGXO6SJou3YZ he4pCCaVLGrjI3YxaRBuq2hY7jz/8okk/xdqldWxGCLhJ47lEKbYqNnUO0rJB5wcqZbw V7Kz/4sk4CwFCkxgDSBcQWUbeQmncmjAQIT8DtNfJfY0l8GFoUBFzRsWfKeBRWfpozy6 dKYzn17ouL33O8fGXjpInDmx7cMz9I2Xd2Ys8Y4a6BMzx1VG26hHY/W0Qb7EBCP53mZs gbbw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q23si633125pfc.179.2019.07.17.19.04.07; Wed, 17 Jul 2019 19:04:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729812AbfGRCBy (ORCPT + 99 others); Wed, 17 Jul 2019 22:01:54 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:2675 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727658AbfGRCBy (ORCPT ); Wed, 17 Jul 2019 22:01:54 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id B923175E6D083B2475B5; Thu, 18 Jul 2019 10:01:52 +0800 (CST) Received: from [127.0.0.1] (10.184.12.158) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.439.0; Thu, 18 Jul 2019 10:01:46 +0800 Subject: Re: [PATCH] KVM: arm/arm64: Assign pmc->idx before kvm_pmu_stop_counter() To: Marc Zyngier , Julien Thierry , , CC: , , , , , , References: <1563366019-31200-1-git-send-email-yuzenghui@huawei.com> <01fa98c1-8274-445c-5e04-219372920ba2@arm.com> <26b64d48-5ff9-7d62-bc44-601fdcc43223@kernel.org> From: Zenghui Yu Message-ID: Date: Thu, 18 Jul 2019 09:59:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 In-Reply-To: <26b64d48-5ff9-7d62-bc44-601fdcc43223@kernel.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.184.12.158] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Julien, Marc, On 2019/7/17 23:00, Marc Zyngier wrote: > On 17/07/2019 14:44, Julien Thierry wrote: >> Hi Zenghui, >> >> On 17/07/2019 13:20, Zenghui Yu wrote: >>> We use "pmc->idx" and the "chained" bitmap to determine if the pmc is >>> chained, in kvm_pmu_pmc_is_chained(). But idx might be uninitialized >>> (and random) when we doing this decision, through a KVM_ARM_VCPU_INIT >>> ioctl -> kvm_pmu_vcpu_reset(). And the test_bit() against this random >>> idx will potentially hit a KASAN BUG [1]. >>> >>> Fix it by moving the assignment of idx before kvm_pmu_stop_counter(). >>> >>> [1] https://www.spinics.net/lists/kvm-arm/msg36700.html >>> >>> Fixes: 80f393a23be6 ("KVM: arm/arm64: Support chained PMU counters") >>> Suggested-by: Andrew Murray >>> Cc: Marc Zyngier >>> Signed-off-by: Zenghui Yu > --- >>> virt/kvm/arm/pmu.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c >>> index 3dd8238..521bfdd 100644 >>> --- a/virt/kvm/arm/pmu.c >>> +++ b/virt/kvm/arm/pmu.c >>> @@ -225,8 +225,8 @@ void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) >>> struct kvm_pmu *pmu = &vcpu->arch.pmu; >>> >>> for (i = 0; i < ARMV8_PMU_MAX_COUNTERS; i++) { >>> - kvm_pmu_stop_counter(vcpu, &pmu->pmc[i]); >>> pmu->pmc[i].idx = i; >> >> Yes, this is kind of a static property that should really be part of a >> "kvm_pmu_vcpu_init()" or "kvm_pmu_vcpu_create()" and is not expected to >> be modified across resets... >> >> There is no such function at the time and I'm unsure whether this >> warrants creating that separate function (I would still suggest creating >> it to make things clearer). > > Yup, that's pretty bad, now that you mention it. I'd be all for the > introduction of kvm_pmu_vcpu_init(), given that we already have > kvm_pmu_vcpu_destroy(). > >> >>> + kvm_pmu_stop_counter(vcpu, &pmu->pmc[i]); >> >> Whatever other opinions are on splitting pmu_vcpu_init/reset, that >> change makes sense and fixes the issue: >> >> Acked-by: Julien Thierry >> >>> } >>> >>> bitmap_zero(vcpu->arch.pmu.chained, ARMV8_PMU_MAX_COUNTER_PAIRS); >>> >> >> Cheers, >> > > Zenghui, could you please update your patch to take the above into account? Sure. I will send a v2 with the new subject (may be "KVM: arm/arm64: Introduce kvm_pmu_vcpu_init() to ..."). Thanks for your suggestions! zenghui