Re: [PATCH v1 09/11] KVM: arm64: Type-check hypercall arguments at the caller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Disabling the hypervisor trace clock fails to stop the background clock synchronization worker.
--

--- Patch [9]: [PATCH v1 09/11] KVM: arm64: Type-check hypercall arguments at the caller ---
commit 171ebbffa4142a86e7fab981732cd83df6923869
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Type-check hypercall arguments at the caller

This commit replaces the untyped kvm_call_hyp_nvhe macro with typed stubs
generated for each declared hypercall. This ensures that hypercall arguments
are checked for correct number and types at compile time.

> diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
> index 2411b4c32932c..7fe0e8feb7d7c 100644
> --- a/arch/arm64/kvm/hyp_trace.c
> +++ b/arch/arm64/kvm/hyp_trace.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but I noticed a logic error in this same file
in hyp_trace_clock_enable() when tracing is disabled:

arch/arm64/kvm/hyp_trace.c:hyp_trace_clock_enable() {
...
        if (!enable) {
                cancel_delayed_work_sync(&hyp_clock->work);
                hyp_clock->running = false;
        }
...

Does this accidentally restart the background clock synchronization worker 
instead of stopping it? 

Without a return statement inside the if (!enable) block, execution appears
to continue down the function. This would cause the worker to be inadvertently
re-initialized and restarted, leaving the background task running and making
periodic __tracing_update_clock hypercalls indefinitely after tracing has
been disabled.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720162412.1401272-1-fuad.tabba@linux.dev?part=9