[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <313E79F2-E277-4C66-97C8-40B545B58370@vmware.com>
Date: Thu, 26 Mar 2020 19:02:33 +0000
From: Nadav Amit <namit@...are.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: x86 <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"mhiramat@...nel.org" <mhiramat@...nel.org>,
"bristot@...hat.com" <bristot@...hat.com>,
"jbaron@...mai.com" <jbaron@...mai.com>,
"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
tglx <tglx@...utronix.de>, "mingo@...nel.org" <mingo@...nel.org>,
"hpa@...or.com" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
"ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
"jpoimboe@...hat.com" <jpoimboe@...hat.com>
Subject: Re: [RESEND][PATCH v3 06/17] static_call: Add basic static call
infrastructure
> On Mar 26, 2020, at 11:28 AM, Peter Zijlstra <peterz@...radead.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.
Powered by blists - more mailing lists