Messages in this thread | | | Date | Fri, 30 Apr 2021 05:54:51 +0800 | From | Changbin Du <> | Subject | Re: [PATCH] RISC-V: insn: Use a raw spinlock to protect TEXT_POKE* |
| |
On Thu, Apr 29, 2021 at 12:30:07PM -0400, Steven Rostedt wrote: > On Wed, 28 Apr 2021 23:17:13 -0700 > Palmer Dabbelt <palmer@dabbelt.com> wrote: > > > From: Palmer Dabbelt <palmerdabbelt@google.com> > > > > We currently use text_mutex to protect the fixmap sections from > > concurrent callers. This is convienent for kprobes as the generic code > > already holds text_mutex, but ftrace doesn't which triggers a lockdep > > assertion. We could take text_mutex for ftrace, but the jump label > > implementation (which is currently taking text_mutex) isn't explicitly > > listed as being sleepable and it's called from enough places it seems > > safer to just avoid sleeping. > > > > arm64 and parisc, the other two TEXT_POKE-style patching > > implemnetations, already use raw spinlocks. abffa6f3b157 ("arm64: > > convert patch_lock to raw lock") lays out the case for a raw spinlock as > > opposed to a regular spinlock, and while I don't know of anyone using rt > > on RISC-V I'm sure it'll eventually show up and I don't see any reason > > to wait. > > On x86 we use text_mutex for jump label and ftrace. I don't understand the > issue here. The arm64 update was already using spin locks in the > insn_write() function itself. riscv just makes sure that text_mutex is held. > > It also looks like ftrace on riscv should also have text_mutex held > whenever it modifies the code. Because I see this in > arch/riscv/kernel/ftrace.c: > > > int ftrace_arch_code_modify_prepare(void) __acquires(&text_mutex) > { > mutex_lock(&text_mutex); > return 0; > } > > int ftrace_arch_code_modify_post_process(void) __releases(&text_mutex) > { > mutex_unlock(&text_mutex); > return 0; > } > > Which should be getting called before and after respectively from when > ftrace does its updates. > > Can you show me the back trace of that lockdep splat? > The problem is that lockdep cannot handle locks across tasks since we use stopmachine to patch code for risc-v. So there's a false positive report. See privious disscussion here: https://lkml.org/lkml/2021/4/29/63
> -- Steve
-- Cheers, Changbin Du
| |