[PATCH] RISC-V: insn: Use a raw spinlock to protect TEXT_POKE*
rostedt at goodmis.org
Thu Apr 29 17:30:07 BST 2021
On Wed, 28 Apr 2021 23:17:13 -0700
Palmer Dabbelt <palmer at dabbelt.com> wrote:
> From: Palmer Dabbelt <palmerdabbelt at 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
int ftrace_arch_code_modify_prepare(void) __acquires(&text_mutex)
int ftrace_arch_code_modify_post_process(void) __releases(&text_mutex)
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?
More information about the linux-riscv