Re: [PATCH 5/5] x86/paravirt: Trace contended_release on unlock

[email protected] Tue, 04 Aug 2026 07:38:45 +0000
Newsgroups org.kernel.vger.linux-hyperv,org.kernel.vger.kvm
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Medium] Paravirt queued spinlocks unconditionally trace 'contended_relea=
se' when the tracepoint is enabled globally, ignoring the CONFIG_QUEUED_SPI=
NLOCKS_TRACE_CONTENDED_RELEASE opt-out.
--

--- Patch [5]: [PATCH 5/5] x86/paravirt: Trace contended_release on unlock =
---
commit 1a2ad2e72bd14437a21c720ae7476112bc7cb8d5
Author: Dmitry Ilvokhin <[email protected]>

x86/paravirt: Trace contended_release on unlock

This commit introduces traced variants of paravirt spinlock unlock functions
to trace the contended_release event. It dynamically swaps the static call
target to point to these traced versions when the tracepoint is enabled,
keeping the disabled path zero-cost.

> diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/parav=
irt-spinlocks.c
> index ddc19dc28ba16..ca12b36553074 100644
> --- a/arch/x86/kernel/paravirt-spinlocks.c
> +++ b/arch/x86/kernel/paravirt-spinlocks.c
[ ... ]
> +int arch_contended_release_trace_reg(void)
> +{
> +	void *cur =3D static_call_query(queued_spin_unlock);
> +
> +	if (cur =3D=3D __raw_callee_save___native_queued_spin_unlock)
> +		static_call_update(queued_spin_unlock,
> +				   __raw_callee_save_native_queued_spin_unlock_traced);
> +	else if (cur =3D=3D __raw_callee_save___pv_queued_spin_unlock)
> +		static_call_update(queued_spin_unlock,
> +				   __raw_callee_save_pv_queued_spin_unlock_traced);
> +	return 0;
> +}

[Severity: Medium]
Will arch_contended_release_trace_reg() unconditionally trace the paravirt
queued spinlocks when the tracepoint is enabled globally, even if the kernel
was built with CONFIG_QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE=3Dn?

It looks like this registration callback swaps the static calls to the trac=
ed
variants without checking if spinlock tracing was explicitly opted out in t=
he
kernel configuration.

> +
> +void arch_contended_release_trace_unreg(void)
> +{
> +	void *cur =3D static_call_query(queued_spin_unlock);
> +
> +	if (cur =3D=3D __raw_callee_save_native_queued_spin_unlock_traced)
> +		static_call_update(queued_spin_unlock,
> +				   __raw_callee_save___native_queued_spin_unlock);
> +	else if (cur =3D=3D __raw_callee_save_pv_queued_spin_unlock_traced)
> +		static_call_update(queued_spin_unlock,
> +				   __raw_callee_save___pv_queued_spin_unlock);
>  }

[Severity: Medium]
Similarly, does arch_contended_release_trace_unreg() also need to check the
CONFIG_QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE configuration?

Without a config guard, this manipulates the static calls when the tracepoi=
nt
is disabled globally, even if spinlock tracing was intentionally excluded
during the build.

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/cover.1785778551.gi=
[email protected]?part=3D5