Messages in this thread | | | From | Nadav Amit <> | Subject | Re: [RESEND][PATCH v3 06/17] static_call: Add basic static call infrastructure | Date | Thu, 26 Mar 2020 19:02:33 +0000 |
| |
> On Mar 26, 2020, at 11:28 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > On Thu, Mar 26, 2020 at 06:09:07PM +0000, Nadav Amit wrote: > >> I think that the kernel underutilizes the pure attribute in general. >> Building it with "-Wsuggest-attribute=pure” results in many warnings. >> Function pointers such kvm_x86_ops.get_XXX() could have been candidates to >> use the “pure” attribute. >> >> The syntax is what you would expect: >> >> static void __attribute__((pure))(*ptr)(void); > > Well, I didn't in fact expect that, because an attribute is not a > type qualifier.
Just a small correction for my stupid example - pure function should always return a value.
>> However, you have a point, gcc does not appear to respect “pure” for >> function pointers and emits a warning it is ignored. GCC apparently only >> respects “const”. In contrast clang appears to respect the pure attribute >> for function pointers. > > Still, we can probably make it happen for static_call(), since it is a > direct call to the trampoline, all we need to do is make sure the > trampoline is declared pure. > > It does however mean that static_call() inherits all the dangers and > pit-falls of function pointers with some extra on top. It will be > impossible to validate this stuff. > > That is, you can static_call_update() with a pointer to a !pure function > and you get to keep the pieces.
I understand. Well, perhaps it can be added later, as anyhow GCC does not support it.
On another note - it may be beneficial to see if the infrastructure that you built can accommodate notifier-chains. It is not the most painful point, but it would be nice to deal with those as well. Since many of those are changed asynchronously, I am not sure it is the easiest thing to do.
| |