summaryrefslogtreecommitdiff
path: root/tools/perf/util/scripting-engines/trace-event-python.c
diff options
context:
space:
mode:
authorMarc Zyngier <maz@kernel.org>2025-02-04 17:55:54 +0300
committerMarc Zyngier <maz@kernel.org>2025-02-04 18:02:16 +0300
commit5417a2e9b130a78bf48cb4cf92630efcee5ccf38 (patch)
tree351dd23461017e71e6d0cf0ee58cf9d082c8136a /tools/perf/util/scripting-engines/trace-event-python.c
parent32392e04cb50d87bb7a6a7d9213f44a1a0961820 (diff)
downloadlinux-5417a2e9b130a78bf48cb4cf92630efcee5ccf38.tar.xz
KVM: arm64: Fix nested S2 MMU structures reallocation
For each vcpu that userspace creates, we allocate a number of s2_mmu structures that will eventually contain our shadow S2 page tables. Since this is a dynamically allocated array, we reallocate the array and initialise the newly allocated elements. Once everything is correctly initialised, we adjust pointer and size in the kvm structure, and move on. But should that initialisation fail *and* the reallocation triggered a copy to another location, we end-up returning early, with the kvm structure still containing the (now stale) old pointer. Weeee! Cure it by assigning the pointer early, and use this to perform the initialisation. If everything succeeds, we adjust the size. Otherwise, we just leave the size as it was, no harm done, and the new memory is as good as the ol' one (we hope...). Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") Reported-by: Alexander Potapenko <glider@google.com> Tested-by: Alexander Potapenko <glider@google.com> Link: https://lore.kernel.org/r/20250204145554.774427-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
Diffstat (limited to 'tools/perf/util/scripting-engines/trace-event-python.c')
0 files changed, 0 insertions, 0 deletions