[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210506092550.6c2206b3@gandalf.local.home>
Date: Thu, 6 May 2021 09:25:50 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Palmer Dabbelt <palmer@...belt.com>
Cc: linux-riscv@...ts.infradead.org, mingo@...hat.com,
Paul Walmsley <paul.walmsley@...ive.com>,
aou@...s.berkeley.edu, mhiramat@...nel.org, zong.li@...ive.com,
guoren@...ux.alibaba.com, Atish Patra <Atish.Patra@....com>,
linux-kernel@...r.kernel.org, kernel-team@...roid.com,
Palmer Dabbelt <palmerdabbelt@...gle.com>,
Changbin Du <changbin.du@...il.com>
Subject: Re: [PATCH] RISC-V: Don't check text_mutex during stop_machine
On Thu, 6 May 2021 00:10:41 -0700
Palmer Dabbelt <palmer@...belt.com> wrote:
> ---
> In theory we should be able to avoid using stop_machine() with some
> clever code sequences, but that's too big of a change to be considered a
> fix. I also can't find the text I thought was in the ISA manual about
> the allowed behaviors for concurrent modification of the instruction
> stream, so I might have just mis-remembered that.
> ---
I wonder if you could at least use break points, as some other archs do,
and what x86 does.
If you have this make believe machine code:
00 00 00 00 nop
And you want to turn it into a call.
aa 12 34 56 bl ftrace_caller
And if your architecture has a way to inject a break point on live code.
Let's call this FF for the break point code.
You can inject that first:
FF 00 00 00
sync all CPUs where now all callers will hit this and jump to the break
point handler, which simply does:
ip = ip + 4;
return;
and returns back to the instruction after this nop/call.
Change the rest of the instruction.
FF 12 34 56
sync all CPUs so that they all see this new instruction, but are still
triggering the break point.
Then finally remove the break point.
aa 12 34 56
And you just switched from the nop to the call without using stop machine.
-- Steve
Powered by blists - more mailing lists