[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190104130648.02657f3f@gandalf.local.home>
Date: Fri, 4 Jan 2019 13:06:48 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Torsten Duwe <duwe@....de>, Will Deacon <will.deacon@....com>,
Catalin Marinas <catalin.marinas@....com>,
Julien Thierry <julien.thierry@....com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Ingo Molnar <mingo@...hat.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
AKASHI Takahiro <takahiro.akashi@...aro.org>,
Amit Daniel Kachhap <amit.kachhap@....com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
live-patching@...r.kernel.org
Subject: Re: [PATCH v6] arm64: implement ftrace with regs
On Fri, 4 Jan 2019 17:50:18 +0000
Mark Rutland <mark.rutland@....com> wrote:
> At Linux Plumbers, I had a conversation with Steve Rostedt, and we came
> to the conclusion that (withut heavyweight synchronization) patching two
> NOPs at runtime isn't safe, since a CPU might have executed the first
> NOP as a NOP before another CPU patches both instructions. So a CPU
> might execute:
>
> NOP
> BL ftrace_regs_caller
>
> ... rather than the expected:
>
> MOV X9, X30
> BL ftrace_regs_caller
>
> ... and therefore X9 contains some UNKNOWN value, rather than the
> original LR value.
>
> I wonder if we could solve that by patching the kernel at build-time, to
> add the MOV X9, X30 in place of the first NOP. If we were to do that, we
> could also update the addresses to pooint at the second NOP, simplifying
> the changes to the runtime code.
You can also patch it at boot up when there's only one CPU running, and
interrupts are disabled.
-- Steve
Powered by blists - more mailing lists