summaryrefslogtreecommitdiffstats
path: root/samples
diff options
context:
space:
mode:
authorZenghui Yu2019-07-18 10:15:10 +0200
committerMarc Zyngier2019-07-23 10:23:44 +0200
commitbca031e2c8aa22a978a2452bf959e27e9fa73dc7 (patch)
treec7e80e707e3abc3d924254432f4159b36b51631f /samples
parentLinus 5.3-rc1 (diff)
downloadkernel-qcow2-linux-bca031e2c8aa22a978a2452bf959e27e9fa73dc7.tar.gz
kernel-qcow2-linux-bca031e2c8aa22a978a2452bf959e27e9fa73dc7.tar.xz
kernel-qcow2-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 'samples')
0 files changed, 0 insertions, 0 deletions