summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2026-09-03 17:24:23 -0700
committerSean Christopherson <seanjc@google.com>2026-09-11 09:35:42 -0700
commit4e824a04d4fad3f2754d0089fb150c043daab732 (patch)
treee85d3082a732dd09ac53eb9b79f29d14a30bea84 /tools/perf/scripts/python/stackcollapse.py
parent6ecd351628f3493060fdd02d8044712ba7af094a (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/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions