On 25/03/2021 08.42, Peter Zijlstra wrote: > On Thu, Mar 25, 2021 at 01:42:41AM +0100, Rasmus Villemoes wrote: >>> Actually, it looks like I can't select PREEMPT_DYNAMIC> and tweaking Kconfig >> >> Ah, there's no prompt on the "bool" line, so it doesn't show up. That >> seems to be a mistake, since there's an elaborate help text which says >> >> The runtime overhead is negligible with >> HAVE_STATIC_CALL_INLINE enabled >> but if runtime patching is not available for the specific >> architecture >> then the potential overhead should be considered. >> >> So it seems that it was meant to be "you can enable this if you really >> want". >> >> to force enable it on arm64 results in a build error > > Right, PREEMPT_DYNAMIC really hard relies on HAVE_STATIC_CALL > > There's an implicit dependency in the select: > > config PREEMPT > ... > select PREEMPT_DYNAMIC if HAVE_PREEMPT_DYNAMIC
That's not a dependency, that's a "force PREEMPT_DYNAMIC on", and users on x86 can't deselect PREEMPT_DYNAMIC even if they wanted to. Having a help text but not providing a prompt string is rather unusual. What's the point of that paragraph I quoted above if PREEMPT_DYNAMIC is not supposed to be settable by the developer? >>> ("implicit declaration of function 'static_call_mod'"). >> >> Seems to be an omission in the last !HAVE_STATIC_CALL branch in >> static_call_types.h, and there's also no >> EXPORT_STATIC_CALL_TRAMP{,_GPL} in static_call.h for that case. > > That interface doesn't make sense for !HAVE_STATIC_CALL. Perhaps, perhaps not. But I think it's silly to have code with such a random hidden dependency, especially when it's only a defense against crazy oot modules and not some fundamental requirement. > It's impossible > to not export the function pointer itself but still call it for > !HAVE_STATIC_CALL. Well, I think there's a way. At this point, the audience is asked to wear sun glasses. // foo.h extern const int foo; extern int __foo_just_for_vmlinux; // foo.c int __foo_just_for_vmlinux; extern const int foo __attribute__((__alias__("__foo_just_for_vmlinux"))); EXPORT_SYMBOL(foo); Modules can read foo, but can't do foo = 5. (Yeah, they can take the address and cast away the const...). Basically, this is a kind of top-level anonymous union trick a la i_nlink/__i_nlink. And it's more or less explicitly said in the gcc docs that this is supposed to work: "Except for top-level qualifiers the alias target must have the same type as the alias." Rasmus