summaryrefslogtreecommitdiffstats
path: root/arch/arm64
diff options
context:
space:
mode:
authorZenghui Yu <yuzenghui@huawei.com>2019-07-18 08:15:10 +0000
committerMarc Zyngier <marc.zyngier@arm.com>2019-07-23 09:23:44 +0100
commitbca031e2c8aa22a978a2452bf959e27e9fa73dc7 (patch)
treec7e80e707e3abc3d924254432f4159b36b51631f /arch/arm64
parent5f9e832c137075045d15cd6899ab0505cfb2ca4b (diff)
downloadlinux-bca031e2c8aa22a978a2452bf959e27e9fa73dc7.tar.gz
linux-bca031e2c8aa22a978a2452bf959e27e9fa73dc7.tar.bz2
linux-bca031e2c8aa22a978a2452bf959e27e9fa73dc7.zip
KVM: arm/arm64: Introduce kvm_pmu_vcpu_init() to setup PMU counter index
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]. In general, idx is the static property of a PMU counter that is not expected to be modified across resets, as suggested by Julien. It looks more reasonable if we can setup the PMU counter idx for a vcpu in its creation time. Introduce a new function - kvm_pmu_vcpu_init() for this basic setup. Oh, and the KASAN BUG will get fixed this way. [1] https://www.spinics.net/lists/kvm-arm/msg36700.html Fixes: 80f393a23be6 ("KVM: arm/arm64: Support chained PMU counters") Suggested-by: Andrew Murray <andrew.murray@arm.com> Suggested-by: Julien Thierry <julien.thierry@arm.com> Acked-by: Julien Thierry <julien.thierry@arm.com> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Diffstat (limited to 'arch/arm64')
0 files changed, 0 insertions, 0 deletions