Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 5 May 2020 11:48:29 -0700 | Subject | Re: [PATCH v4 14/18] static_call: Add static_cond_call() |
| |
On Tue, May 5, 2020 at 11:28 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > Changing > void *func = READ_ONCE(name.func); \ > to > void *func = &READ_ONCE(name.func); \
What? That makes no sense.
Yes,
void *func = foo;
and
void *func = &foo;
are the same thing, _if_ "foo" is an actual function, because then "foo" degrades from a function to a pointer to a function as part of C type semantics.
But that's not the case here. READ_ONCE(name.func) isn't a function - it's a pointer to a function. So it doesn't degrade to anything at all, and adding a '&' in front ot it completely changes the meaning of the expression. So now the '&' changes it from "pointer to a function" to "pointer to a pointer to a function", and the end result is not the same thing any more.
Without the "&" it will call the function "bar" (which is the function pointer that was assigned).
With the "&", it will not not call a function at all, it will do a call to an address that is actually data of type "struct static_call_key".
That's also why the NULL pointer check goes away: now the pointer is a pointer to static data, which can never be NULL.
That said, I found it interesting that the volatile read also goes away. That struck me as strange. But then I thought about it somem more, and realized that the '&' basically just peels off the '*', so now there isn't any actual volatile access any more, which is why the read went away too.
Anyway, adding that '&' completely changes the meaning of the test.
Your initial reaction that "you can't compile away the read and the test of NULL" was correct, I think.
Linus
| |