[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <061a4299-114f-96e0-86a4-6ab255778498@huawei.com>
Date: Tue, 24 May 2022 22:24:55 +0800
From: Chen Zhongjin <chenzhongjin@...wei.com>
To: <madvenka@...ux.microsoft.com>, <jpoimboe@...hat.com>,
<peterz@...radead.org>, <mark.rutland@....com>,
<broonie@...nel.org>, <nobuta.keiya@...itsu.com>,
<sjitindarsingh@...il.com>, <catalin.marinas@....com>,
<will@...nel.org>, <jamorris@...ux.microsoft.com>,
<linux-arm-kernel@...ts.infradead.org>,
<live-patching@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 00/20] arm64: livepatch: Use ORC for dynamic frame
pointer validation
Hi Madvenka,
I have a brief look at your patch and the idea that using CFA metadata to
validate FP is reasonable to me. And I found a problem when I used 'pv dump' to
check the orc value and I replied your commit 11/20 for that.
I think it's not necessary that you rewrite the arm64 decoder(there is already a
decoder in my patch) and insn check(objtool check can just make it) by yourself.
Especially it is too duplicated to have two check in objtool.
For me it's also a trouble that objtool runs too much unnecessary work. I advise
that we should move some check for x86 as arch specific and refactor the cmdline
options, they doesn't turn off everything perfectly now.
Other than that I have an advise: We only use orc for reliable stacktrace and
normal FP unwind doesn't depends on it. Should we only load these data for
livepatch (or other scenario needs reliable stacktrace)? It can save the memory
and time consuming for kernel.
That's all. And if you don't mind, can I incorporate some commit into my set?
Appreciate for it.
Best,
Chen
Powered by blists - more mailing lists