diff options
| author | Sean Christopherson <seanjc@google.com> | 2026-09-03 17:24:23 -0700 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2026-09-11 09:35:42 -0700 |
| commit | 4e824a04d4fad3f2754d0089fb150c043daab732 (patch) | |
| tree | e85d3082a732dd09ac53eb9b79f29d14a30bea84 /tools/perf/scripts/python/parallel-perf.py | |
| parent | 6ecd351628f3493060fdd02d8044712ba7af094a (diff) | |
KVM: selftests: Always assert that vmreadz() succeeds
Rename vmreadz() => vmread() (and vmread() => __vmread()) and have it
assert success instead of returning garbage on failure. While the eVMCS
path avoids clobbering *value on failure, the VMREAD path unconditionally
stores tmp to *value, without ever zeroing tmp. I.e. if VMREAD did fail,
*value would be loaded with random stack data, not '0'.
An audit of the code confirms that nothing is actually relying on vmreadz()
to zero the result on failure, as all paths either check for a non-zero
value, propagate the result into vmwrite(), or guard the vmread() with a
pre-check that the field exists.
Opportunistically fix the bug in what is now __vmread(), so that the code
isn't consuming uninitialized stack data. Begrudgingly keep zeroing
value in vmread(), as gcc-15 at least isn't smart enough to figure out
that value won't be used uninitialized (though to be fair, strictly
speaking it isn't actually unreachable code).
Link: https://patch.msgid.link/20260904002423.3154436-18-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/perf/scripts/python/parallel-perf.py')
0 files changed, 0 insertions, 0 deletions
