[PATCH v2 2/2] arm64: ftrace: add support for far branches to dynamic ftrace

On 7 June 2017 at 15:46, Steven Rostedt [off-list ref] wrote:

On Mon, 5 Jun 2017 18:15:35 +0100
Will Deacon [off-list ref] wrote:

quoted

quoted

+           tramp = (unsigned long *)mod->arch.ftrace_trampoline->sh_addr;
+           if (tramp[0] != addr) {
+                   if (tramp[0] != 0) {
+                           pr_err("ftrace: far branches to multiple entry points unsupported inside a single module\n");
+                           return AARCH64_BREAK_FAULT;
+                   }
+
+                   /* point the trampoline to our ftrace entry point */
+                   module_disable_ro(mod);
+                   tramp[0] = addr;
+                   module_enable_ro(mod, true);

I'm not sure what the barrier semantics are for module_enable_ro, but I'd be
inclined to stick in a smp_wmb() here to order the write of the trampoline
data before the writing of the branch instruction.

I would assume that module_disable/enable_ro() has proper barriers for
modifying the page tables with respect to code around it, otherwise it
would probably be an issues elsewhere in the kernel. Specifically in
the module code itself.

I don't see how a smp_wmb() would be needed here, especially since this
is serialized code, and not something done by multiple CPUs.

But other cores could be invoking the function we are patching here,
no? So when such a core observes (and executes) the updated
instruction before it observes the updated target field of the
trampoline, it will branch to address 0x0.