Re: [PATCH v12 07/12] static_call: Define EXPORT_STATIC_CALL_FOR_MODULES()

From: Sean Christopherson

Date: Tue Jul 28 2026 - 15:02:48 EST


On Wed, Jun 24, 2026, Sean Christopherson wrote:
> On Tue, Jun 23, 2026, Pawan Gupta wrote:
> > There is EXPORT_STATIC_CALL_TRAMP() that hides the static key from all
> > modules. But there is no equivalent of EXPORT_SYMBOL_FOR_MODULES() to
> > restrict symbol visibility to only certain modules.
> >
> > Add EXPORT_STATIC_CALL_FOR_MODULES(name, mods) that wraps both the key and
> > the trampoline with EXPORT_SYMBOL_FOR_MODULES(), allowing only a limited
> > set of modules to see and update the static key.
> >
> > The immediate user is KVM, in the following commit.
> >
> > checkpatch reported below warnings with this change that I believe don't
> > apply in this case:
> >
> > include/linux/static_call.h:219: WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
> > include/linux/static_call.h:220: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
> >
> > Suggested-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx>
> > ---
> > include/linux/static_call.h | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/include/linux/static_call.h b/include/linux/static_call.h
> > index 78a77a4ae0ea..b610afd1ed55 100644
> > --- a/include/linux/static_call.h
> > +++ b/include/linux/static_call.h
> > @@ -216,6 +216,9 @@ extern long __static_call_return0(void);
> > #define EXPORT_STATIC_CALL_GPL(name) \
> > EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)); \
> > EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name))
> > +#define EXPORT_STATIC_CALL_FOR_MODULES(name, mods) \
> > + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_KEY(name), mods); \
> > + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_TRAMP(name), mods)
> >
> > /* Leave the key unexported, so modules can't change static call targets: */
> > #define EXPORT_STATIC_CALL_TRAMP(name) \
> > @@ -276,6 +279,9 @@ extern long __static_call_return0(void);
> > #define EXPORT_STATIC_CALL_GPL(name) \
> > EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)); \
> > EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name))
> > +#define EXPORT_STATIC_CALL_FOR_MODULES(name, mods) \
> > + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_KEY(name), mods); \
> > + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_TRAMP(name), mods)
> >
> > /* Leave the key unexported, so modules can't change static call targets: */
> > #define EXPORT_STATIC_CALL_TRAMP(name) \
> > @@ -346,6 +352,8 @@ static inline int static_call_text_reserved(void *start, void *end)
> >
> > #define EXPORT_STATIC_CALL(name) EXPORT_SYMBOL(STATIC_CALL_KEY(name))
> > #define EXPORT_STATIC_CALL_GPL(name) EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name))
> > +#define EXPORT_STATIC_CALL_FOR_MODULES(name, mods) \
> > + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_KEY(name), mods)
> >
> > #endif /* CONFIG_HAVE_STATIC_CALL */
>
> Drat, I forgot about this. Exporting static call trampolines for KVM came up in
> another conversation[*]. I had already put together patches to effectively default
> to exporting only the trampoline, and also to deduplicate this code so that the
> CONFIG_HAVE_STATIC_CALL_INLINE=y / CONFIG_HAVE_STATIC_CALL=y / CONFIG_HAVE_STATIC_CALL=n
> implementations don't need to copy+paste the same lines of code.
>
> The attached patches touch a lot more code, and will conflict mightily with KVM
> changes I want to land in 7.3 (more use of a static_call in KVM). But if we get
> them applied (to tip tree) shortly after 7.2-rc1 and provide a topic branch/tag,
> then there shouldn't be too much juggling needed?
>
> If we want to go with the more aggressive cleanup, I'll formally post the patches.

*sigh*

So the patches build, but they aren't fully functional. If kvm.ko is built as a
module, trying to load a vendor module will fail due to the trampoline => key table
only tracking built-in symbols.

Given that all of this is KVM, and that it's far easier to export the static calls
if and only if there are vendor modules, and only for those vendor modules, I'm
going to drop the aggressive cleanup and abandon converting KVM's exports to only
export trampolines, at least until someone else works up the motivation to add
support for modules.

> [*] https://lore.kernel.org/all/ahhoDGUz39KSGZ6o@xxxxxxxxxx