Re: [PATCH v7 07/10] x86/vmscape: Use static_call() for predictor flush
From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date: 2026-03-20 18:23:14
Also in:
bpf, kvm, linux-doc, lkml
On Fri, Mar 20, 2026 at 12:31:34PM +0100, Borislav Petkov wrote:
On Fri, Mar 20, 2026 at 10:03:40AM +0100, Peter Zijlstra wrote:quoted
On Thu, Mar 19, 2026 at 11:22:06PM -0700, Pawan Gupta wrote:quoted
This plus extending it to support EXPORT_STATIC_CALL_FOR_KVM() is probably a better solution. Please let me know which one you prefer.The EXPORT twiddling will do I suppose. I'll try and not forget looking at doing the RO static_call thing some time.Dunno, but exporting a static_call sounds really really wrong to me. No matter where. As in: we're exporting the underlying inner workings of it and that should be a big fat no-no.
I am curious, what problems do you anticipate? There are nearly 50 instances of static key being exported. For example: $ git grep -A1 -n DEFINE_STATIC_KEY | grep -B 1 EXPORT_SYMBOL arch/arm64/kernel/mte.c:34:DEFINE_STATIC_KEY_FALSE(mte_async_or_asymm_mode); arch/arm64/kernel/mte.c-35-EXPORT_SYMBOL_GPL(mte_async_or_asymm_mode); -- arch/arm64/kernel/rsi.c:22:DEFINE_STATIC_KEY_FALSE_RO(rsi_present); arch/arm64/kernel/rsi.c-23-EXPORT_SYMBOL(rsi_present); -- arch/powerpc/kernel/firmware.c:25:DEFINE_STATIC_KEY_FALSE(kvm_guest); arch/powerpc/kernel/firmware.c-26-EXPORT_SYMBOL_GPL(kvm_guest); ... Since EXPORT_STATIC_CALL_FOR_KVM() exports only to a module that needs it, it limits the scope of the problem.
So definitely +1 on exporting the helper instead.
The helper approach can be easily replaced with the static_call export later. I can go with the helper for now.