Re: [PATCH v12 07/12] static_call: Define EXPORT_STATIC_CALL_FOR_MODULES()
Pawan Gupta <[email protected]>
| Newsgroups | org.kernel.vger.linux-doc,org.kernel.vger.bpf,org.kernel.vger.kvm,org.kernel.vger.linux-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <4cemrcri4enbau4wfv7rmdbnzxi24j2b7cmkjlczbdzhq36fmk@nrnfjspbd7ns> |
On Tue, Jul 28, 2026 at 11:52:41AM -0700, Sean Christopherson wrote: > 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 <[email protected]> > > > Signed-off-by: Pawan Gupta <[email protected]> > > > --- > > > 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. Thanks for the update. Keeping this patch in the series.