Messages in this thread | | | From | Zong Li <> | Date | Fri, 3 Apr 2020 17:04:51 +0800 | Subject | Re: [PATCH v3 8/9] riscv: introduce interfaces to patch kernel code |
| |
On Thu, Apr 2, 2020 at 9:17 AM Masami Hiramatsu <mhiramat@kernel.org> wrote: > > Hi, > > On Wed, 1 Apr 2020 15:42:30 +0800 > Zong Li <zong.li@sifive.com> wrote: > > > > > + > > > > +static int __kprobes riscv_insn_write(void *addr, const void *insn, size_t len) > > > > > > Why would you add "riscv_" prefix for those functions? It seems a bit odd. > > > > There is no particular reason, I just was used to adding a prefix for > > arch-related stuff. I have no preference here, it's OK to me to remove > > the prefix of these functions, do you think we need to remove them? > > Yeah, it will be better, unless it can mixed up with arch-independent > functions.
OK. I'll remove it and use NOKPROBE_SYMBOL() instead of __kprobes annotation.
> > > > > +{ > > > > + void *waddr = addr; > > > > + bool across_pages = (((uintptr_t) addr & ~PAGE_MASK) + len) > PAGE_SIZE; > > > > + unsigned long flags = 0; > > > > + int ret; > > > > + > > > > + raw_spin_lock_irqsave(&patch_lock, flags); > > > > > > This looks a bit odd since stop_machine() is protected by its own mutex, > > > and also the irq is already disabled here. > > > > We need it because we don't always enter the riscv_patch_text_nosync() > > through stop_machine mechanism. If we call the > > riscv_patch_text_nosync() directly, we need a lock to protect the > > page. > > Oh, OK, but it leads another question. Is that safe to patch the > text without sync? Would you use it for UP system? > I think it is better to clarify "in what case user can call _nosync()" > and add a comment on it.
The ftrace is one of the cases, as documentation of ftrace said, when dynamic ftrace is initialized, it calls kstop_machine to make the machine act like a uniprocessor so that it can freely modify code without worrying about other processors executing that same code. So the ftrace called the _nosync interface here directly.
> > Thank you, > > > > > > > > > Thank you, > > > > > > > + > > > > + if (across_pages) > > > > + patch_map(addr + len, FIX_TEXT_POKE1); > > > > + > > > > + waddr = patch_map(addr, FIX_TEXT_POKE0); > > > > + > > > > + ret = probe_kernel_write(waddr, insn, len); > > > > + > > > > + patch_unmap(FIX_TEXT_POKE0); > > > > + > > > > + if (across_pages) > > > > + patch_unmap(FIX_TEXT_POKE1); > > > > + > > > > + raw_spin_unlock_irqrestore(&patch_lock, flags); > > > > + > > > > + return ret; > > > > +} > > > > +#else > > > > +static int __kprobes riscv_insn_write(void *addr, const void *insn, size_t len) > > > > +{ > > > > + return probe_kernel_write(addr, insn, len); > > > > +} > > > > +#endif /* CONFIG_MMU */ > > > > + > > > > +int __kprobes riscv_patch_text_nosync(void *addr, const void *insns, size_t len) > > > > +{ > > > > + u32 *tp = addr; > > > > + int ret; > > > > + > > > > + ret = riscv_insn_write(tp, insns, len); > > > > + > > > > + if (!ret) > > > > + flush_icache_range((uintptr_t) tp, (uintptr_t) tp + len); > > > > + > > > > + return ret; > > > > +} > > > > + > > > > +static int __kprobes riscv_patch_text_cb(void *data) > > > > +{ > > > > + struct riscv_insn_patch *patch = data; > > > > + int ret = 0; > > > > + > > > > + if (atomic_inc_return(&patch->cpu_count) == 1) { > > > > + ret = > > > > + riscv_patch_text_nosync(patch->addr, &patch->insn, > > > > + GET_INSN_LENGTH(patch->insn)); > > > > + atomic_inc(&patch->cpu_count); > > > > + } else { > > > > + while (atomic_read(&patch->cpu_count) <= num_online_cpus()) > > > > + cpu_relax(); > > > > + smp_mb(); > > > > + } > > > > + > > > > + return ret; > > > > +} > > > > + > > > > +int __kprobes riscv_patch_text(void *addr, u32 insn) > > > > +{ > > > > + struct riscv_insn_patch patch = { > > > > + .addr = addr, > > > > + .insn = insn, > > > > + .cpu_count = ATOMIC_INIT(0), > > > > + }; > > > > + > > > > + return stop_machine_cpuslocked(riscv_patch_text_cb, > > > > + &patch, cpu_online_mask); > > > > +} > > > > -- > > > > 2.25.1 > > > > > > > > > > > > > -- > > > Masami Hiramatsu <mhiramat@kernel.org> > > > -- > Masami Hiramatsu <mhiramat@kernel.org>
| |