From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
To: Chen Zhongjin <chenzhongjin@huawei.com>,
jpoimboe@redhat.com, peterz@infradead.org, mark.rutland@arm.com,
broonie@kernel.org, nobuta.keiya@fujitsu.com,
sjitindarsingh@gmail.com, catalin.marinas@arm.com,
will@kernel.org, jamorris@linux.microsoft.com,
linux-arm-kernel@lists.infradead.org,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 00/20] arm64: livepatch: Use ORC for dynamic frame pointer validation
Date: Sun, 29 May 2022 10:30:08 -0500 [thread overview]
Message-ID: <2b8d8fbe-e596-91bf-a63b-938c9ff4140a@linux.microsoft.com> (raw)
In-Reply-To: <061a4299-114f-96e0-86a4-6ab255778498@huawei.com>
Thanks for taking the time to review my patches.
On 5/24/22 09:24, Chen Zhongjin wrote:
> 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 have responded to that comment in another email. Please take a look.
> 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.
>
This is a fair point. I will think about this a little bit and respond to this in a separate email.
> 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.
>
So, Josh has done what you have mentioned. He has reorganized all of that code.
I am working on syncing up to his changes. I will send out version 3.
> 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.
>
Yes. For ARM64, that is what I am trying to do. STACK_VALIDATION is optional and it
is off by default. It needs to be turned on only if reliable stack trace is required.
> That's all. And if you don't mind, can I incorporate some commit into my set?
> Appreciate for it.
>
Please feel free to use any and all of my code. I am also looking at merging our two
decoders so that there is only one decoder. I need to think about this a little bit.
So, stay tuned.
Thanks!
Madhavan
WARNING: multiple messages have this Message-ID (diff)
From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
To: Chen Zhongjin <chenzhongjin@huawei.com>,
jpoimboe@redhat.com, peterz@infradead.org, mark.rutland@arm.com,
broonie@kernel.org, nobuta.keiya@fujitsu.com,
sjitindarsingh@gmail.com, catalin.marinas@arm.com,
will@kernel.org, jamorris@linux.microsoft.com,
linux-arm-kernel@lists.infradead.org,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 00/20] arm64: livepatch: Use ORC for dynamic frame pointer validation
Date: Sun, 29 May 2022 10:30:08 -0500 [thread overview]
Message-ID: <2b8d8fbe-e596-91bf-a63b-938c9ff4140a@linux.microsoft.com> (raw)
In-Reply-To: <061a4299-114f-96e0-86a4-6ab255778498@huawei.com>
Thanks for taking the time to review my patches.
On 5/24/22 09:24, Chen Zhongjin wrote:
> 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 have responded to that comment in another email. Please take a look.
> 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.
>
This is a fair point. I will think about this a little bit and respond to this in a separate email.
> 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.
>
So, Josh has done what you have mentioned. He has reorganized all of that code.
I am working on syncing up to his changes. I will send out version 3.
> 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.
>
Yes. For ARM64, that is what I am trying to do. STACK_VALIDATION is optional and it
is off by default. It needs to be turned on only if reliable stack trace is required.
> That's all. And if you don't mind, can I incorporate some commit into my set?
> Appreciate for it.
>
Please feel free to use any and all of my code. I am also looking at merging our two
decoders so that there is only one decoder. I need to think about this a little bit.
So, stay tuned.
Thanks!
Madhavan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-29 15:30 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <e81e773678f88f7c2ff7480e2eb096973ec198db>
2022-05-24 0:16 ` [RFC PATCH v2 00/20] arm64: livepatch: Use ORC for dynamic frame pointer validation madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 01/20] objtool: Reorganize CFI code madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 02/20] objtool: Reorganize instruction-related code madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 03/20] objtool: Move decode_instructions() to a separate file madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 04/20] objtool: Reorganize Unwind hint code madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 05/20] objtool: Reorganize ORC types madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 14:27 ` Chen Zhongjin
2022-05-24 14:27 ` Chen Zhongjin
2022-05-29 15:36 ` Madhavan T. Venkataraman
2022-05-29 15:36 ` Madhavan T. Venkataraman
2022-05-24 0:16 ` [RFC PATCH v2 06/20] objtool: Reorganize ORC code madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 07/20] objtool: Reorganize ORC kernel code madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 08/20] objtool: arm64: Implement decoder for FP validation madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 09/20] objtool: arm64: Implement command to invoke the decoder madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 14:09 ` Mark Brown
2022-05-24 14:09 ` Mark Brown
2022-05-29 14:49 ` Madhavan T. Venkataraman
2022-05-29 14:49 ` Madhavan T. Venkataraman
2022-05-30 7:51 ` Peter Zijlstra
2022-05-30 7:51 ` Peter Zijlstra
2022-06-01 22:45 ` Madhavan T. Venkataraman
2022-06-01 22:45 ` Madhavan T. Venkataraman
2022-06-07 18:13 ` Madhavan T. Venkataraman
2022-06-07 18:13 ` Madhavan T. Venkataraman
2022-05-24 0:16 ` [RFC PATCH v2 10/20] objtool: arm64: Compute destinations for call and jump instructions madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 11/20] objtool: arm64: Walk instructions and compute CFI for each instruction madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 13:45 ` Chen Zhongjin
2022-05-24 13:45 ` Chen Zhongjin
2022-05-29 15:18 ` Madhavan T. Venkataraman
2022-05-29 15:18 ` Madhavan T. Venkataraman
2022-05-30 1:44 ` Chen Zhongjin
2022-05-30 1:44 ` Chen Zhongjin
2022-05-24 0:16 ` [RFC PATCH v2 12/20] objtool: arm64: Generate ORC data from CFI for object files madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 13/20] objtool: arm64: Dump ORC data present in " madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 14/20] objtool: arm64: Add unwind hint support madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 15/20] arm64: Add unwind hints to specific points in code madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 16/20] arm64: Add kernel and module support for ORC madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 17/20] arm64: Build the kernel with ORC information madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 18/20] arm64: unwinder: Add a reliability check in the unwinder based on ORC madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 0:16 ` [RFC PATCH v2 19/20] arm64: Miscellaneous changes required for enabling livepatch madvenka
2022-05-24 0:16 ` madvenka
2022-07-01 14:16 ` Miroslav Benes
2022-07-01 14:16 ` Miroslav Benes
2022-07-01 19:53 ` Madhavan T. Venkataraman
2022-07-01 19:53 ` Madhavan T. Venkataraman
2022-05-24 0:16 ` [RFC PATCH v2 20/20] arm64: Enable livepatch for ARM64 madvenka
2022-05-24 0:16 ` madvenka
2022-05-24 14:24 ` [RFC PATCH v2 00/20] arm64: livepatch: Use ORC for dynamic frame pointer validation Chen Zhongjin
2022-05-24 14:24 ` Chen Zhongjin
2022-05-29 15:30 ` Madhavan T. Venkataraman [this message]
2022-05-29 15:30 ` Madhavan T. Venkataraman
2022-06-15 12:18 ` Ivan T. Ivanov
2022-06-15 12:18 ` Ivan T. Ivanov
2022-06-15 13:37 ` Mark Rutland
2022-06-15 13:37 ` Mark Rutland
2022-06-15 14:18 ` Ivan T. Ivanov
2022-06-15 14:18 ` Ivan T. Ivanov
2022-06-15 20:50 ` Madhavan T. Venkataraman
2022-06-15 20:50 ` Madhavan T. Venkataraman
2022-06-15 20:47 ` Madhavan T. Venkataraman
2022-06-15 20:47 ` Madhavan T. Venkataraman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2b8d8fbe-e596-91bf-a63b-938c9ff4140a@linux.microsoft.com \
--to=madvenka@linux.microsoft.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=chenzhongjin@huawei.com \
--cc=jamorris@linux.microsoft.com \
--cc=jpoimboe@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=nobuta.keiya@fujitsu.com \
--cc=peterz@infradead.org \
--cc=sjitindarsingh@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.