On Tue, 9 Nov 2021 at 19:38, Peter Zijlstra [off-list ref] wrote:
On Tue, Nov 09, 2021 at 05:45:43PM +0100, Ard Biesheuvel wrote:
quoted
The main reason for the existence of static_call_cond() seems to be that
in theory, when using the generic implementation of static calls, it may
be possible for a compiler to elide the indirect call entirely if the
target is NULL, while still guaranteeing that all side effects of
argument evaluation occur as expected.
This is rather optimistic: as documented by an existing code comment,
both GCC and Clang (version 10) get this wrong, and even if they ever
get it right, this is far too subtle to rely on for a code path that is
expected to be used only by the 'remaining' architectures once all the
best supported ones implement either the out-of-line or inline optimized
variety of static calls.
Given that having static_call_cond() clutters up the API, and puts the
burden on the caller to go and check what kind of static call they are
dealing with, let's just get rid of the distinction.
No, static_call_cond() signifies the function can be NULL. Both gcc and
clang generate correct (but wildly ineffecient) code for this. Without
static_call_cond() the generic implementation will do a NULL deref.
That is, static_call_cond() does properly encapuslate:
func = READ_ONCE(key.func);
if (func)
func(ARGS);
You can't take that out.
I actually address that in the patch.
AIUI, the compiler generates an indirect call to __static_call_nop(),
right? So why not simply set .func to the address of
__static_call_nop() when NULL is passed to update / the initializer?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel