Messages in this thread | | | Date | Mon, 21 Mar 2022 19:40:08 -0700 (PDT) | Subject | Re: [PATCH] riscv: ftrace: no need to acquire text_mutex when executed in stop_machine | From | Palmer Dabbelt <> |
| |
On Sun, 13 Mar 2022 00:07:11 PST (-0800), changbin.du@gmail.com wrote: > On Thu, Mar 10, 2022 at 09:27:42AM -0500, Steven Rostedt wrote: >> On Thu, 10 Mar 2022 12:54:54 +0800 >> Changbin Du <changbin.du@gmail.com> wrote: >> >> > It's safe to patch text segment in stop_machine. No race is possible here. >> > Besides, there is a false positive for the lock assertion in >> > patch_insn_write() since the lock is not held by cpu migration thread. >> > >> > So we actually don't need our ftrace_arch_code_modify_prepare/post(). And >> > the lock assertion in patch_insn_write() should be removed to avoid >> > producing lots of false positive warnings. >> > >> > Signed-off-by: Changbin Du <changbin.du@gmail.com> >> >> Ideally, RISC-V should try to get off of the stop_machine approach, and >> move to the breakpoint modification. >> > yes, that's a further step. I can feel a obvious stall to enable ftrace running > in QEMU. (maybe qemu-riscv tcg is too slow...)
Looks like we've had this exact discussion before, even with exactly the same patch and people and everything. I guess I dropped the ball here, I got so distracted trying to figure out those sequences to avoid stop_machine() that I forgot to clean up the patch to fix stop machine. I just sent out a v2 <20220322022331.32136-1-palmer@rivosinc.com>. That should at least fix the crash, we can deal with getting rid of stop_machine() later.
| |