Re: [PATCH v3 4/4] KVM: selftests: loongarch: Add PV TLB flush performance test

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Omission of new selftest file from the KVM selftests Makefile.
- [Medium] The test bypasses the automated KVM selftests framework and requires manual execution inside a guest OS.
- [Medium] Integer overflow during argument parsing leads to stack buffer overflow.
--

commit 3eef713b92a18797245bf05fb771c17910daf380
Author: Tao Cui <cuitao@kylinos.cn>

KVM: selftests: loongarch: Add PV TLB flush performance test
    
Add a multi-threaded benchmark to measure PV TLB flush performance
inside LoongArch KVM guests.

> diff --git a/tools/testing/selftests/kvm/loongarch/pv_tlb_flush_test.c b/tools/testing/selftests/kvm/loongarch/pv_tlb_flush_test.c
> new file mode 100644
> index 0000000000000..63efaf9ef1cd0
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/loongarch/pv_tlb_flush_test.c

[Severity: Medium]
Is this test intentionally omitted from the build system Makefile?

According to the KVM selftests subsystem guidelines, any newly created test
file must be integrated into the test Makefile. Because this file is not
added to TEST_PROGS, TEST_GEN_PROGS, or TEST_FILES, the automated build
system completely ignores it and the test won't be compiled or installed
when make or make install is run.

> @@ -0,0 +1,194 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * LoongArch PV TLB Flush Performance Test
> + *
> + * Measure the overhead of remote TLB flushes in a KVM guest by spawning
> + * flusher threads that repeatedly mmap/munmap (triggering TLB shootdown
> + * IPIs) alongside idle threads that either sleep or busy-spin.
> + *
> + * With PV TLB flush enabled, IPIs to preempted vCPUs are replaced by
> + * deferred flags in the steal-time shared page, reducing flush latency.
> + *
> + * Usage:
> + *   Compile on LoongArch guest:
> + *     gcc -O2 -static -pthread -o pv_tlb_flush_test pv_tlb_flush_test.c
> + *   Run (inside KVM guest):
> + *     ./pv_tlb_flush_test <flushers> <idle> <iterations> <busy_idle>

[Severity: Medium]
Does this bypass the automated KVM selftests framework by requiring manual
execution inside a guest OS?

KVM selftests in tools/testing/selftests/kvm/ are designed as host-side
executables that programmatically create bare-metal micro-VMs to test KVM
ioctls. 

This patch introduces a standalone POSIX user-space program (using pthreads
and the standard C library) that is explicitly designed to be manually
compiled and executed from within a full Linux guest OS. This fundamentally
violates the architectural model of the KVM selftests framework.

[ ... ]

> +int main(int argc, char **argv) {
> +    int nr_flush = 1, nr_idle = 3, i, run;
> +    int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
> +    if (argc > 1) nr_flush = atoi(argv[1]);
> +    if (argc > 2) nr_idle = atoi(argv[2]);
> +    if (argc > 3) nr_iters = atoi(argv[3]);
> +    if (argc > 4) busy_idle = atoi(argv[4]);
> +
> +    if (nr_flush < 1 || nr_idle < 0 || nr_flush + nr_idle > MAX_THREADS) {

[Severity: Medium]
Can this bounds check suffer from integer overflow?

If a user supplies large positive numbers for nr_flush and nr_idle (e.g.,
2,000,000,000) parsed via atoi(), their sum could overflow into a negative
32-bit signed integer. This would bypass the MAX_THREADS check.

The subsequent for loops would then use the original large positive values
to iterate millions of times, writing far out of bounds on the 64-element
stack allocated arrays (threads, results, completed, args), corrupting
the stack.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602021819.2373404-1-cui.tao@linux.dev?part=4