lkml.org 
[lkml]   [2020]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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

\
 
 \ /
  Last update: 2020-05-05 20:57    [W:0.144 / U:1.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site