[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 5 May 2020 11:48:29 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Jason Baron <jbaron@...mai.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>, Nadav Amit <namit@...are.com>,
"H. Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...nel.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
"H.J. Lu" <hjl.tools@...il.com>,
clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH v4 14/18] static_call: Add static_cond_call()
On Tue, May 5, 2020 at 11:28 AM Nick Desaulniers
<ndesaulniers@...gle.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
Powered by blists - more mailing lists