From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
jpoimboe@redhat.com, peterz@infradead.org,
chenzhongjin@huawei.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 v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation
Date: Thu, 13 Apr 2023 09:59:31 -0500 [thread overview]
Message-ID: <cf583799-1a8d-4dd2-8bc7-c8fbb07f29ab@linux.microsoft.com> (raw)
In-Reply-To: <20230412155221.2l2mqsyothseymeq@treble>
On 4/12/23 10:52, Josh Poimboeuf wrote:
> On Wed, Apr 12, 2023 at 09:50:23AM -0500, Madhavan T. Venkataraman wrote:
>>>> I read through the SFrame spec file briefly. It looks like I can easily adapt my
>>>> version 1 of the livepatch patchset which was based on DWARF to SFrame. If the compiler
>>>> folks agree to properly support and maintain SFrame, then I could send the next version
>>>> of the patchset based on SFrame.
>>>>
>>>> But I kinda need a clear path forward before I implement anything. I request the arm64
>>>> folks to comment on the above approach. Would it be useful to initiate an email discussion
>>>> with the compiler folks on what they plan to do to support SFrame? Or, should this all
>>>> happen face to face in some forum like LPC?
>>>
>>> SFrame is basically a simplified version of DWARF unwind, using it as an
>>> input to objtool is going to have the same issues I mentioned below (and
>>> as was discussed with your v1).
>>>
>>
>> Yes. It is a much simplified version of DWARF. So, I am hoping that the compiler folks
>> can provide the feature with a reliability guarantee. DWARF is too complex.
>
> I don't see what the complexity (or lack thereof) of the unwinding data
> format has to do with it. The unreliability comes from the underlying
> data source, not the formatting of the data.
>
What I meant is - if SFrame is implemented by simply extracting unwind info from
DWARF data and placing it in a separate section (as it is probably implemented now),
then what you say is totally true. But if the compiler folks agree to make SFrame reliable,
then either they have to make DWARF reliable. Or, they have to implement SFrame as a
separate feature and make it reliable. The former is tough to do as DWARF has a lot of complexity.
The latter is a lot easier to do.
Sorry if that was not clear.
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:[~2023-04-13 15:00 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0337266cf19f4c98388e3f6d09f590d9de258dc7>
2023-02-02 7:40 ` [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation madvenka
2023-02-02 7:40 ` [RFC PATCH v3 01/22] objtool: Reorganize CFI code madvenka
2023-02-02 7:40 ` [RFC PATCH v3 02/22] objtool: Reorganize instruction-related code madvenka
2023-02-02 7:40 ` [RFC PATCH v3 03/22] objtool: Move decode_instructions() to a separate file madvenka
2023-02-02 7:40 ` [RFC PATCH v3 04/22] objtool: Reorganize Unwind hint code madvenka
2023-02-02 7:40 ` [RFC PATCH v3 05/22] objtool: Reorganize ORC types madvenka
2023-02-18 9:30 ` Suraj Jitindar Singh
2023-03-06 16:45 ` Madhavan T. Venkataraman
2023-02-02 7:40 ` [RFC PATCH v3 06/22] objtool: Reorganize ORC code madvenka
2023-02-02 7:40 ` [RFC PATCH v3 07/22] objtool: Reorganize ORC kernel code madvenka
2023-02-02 7:40 ` [RFC PATCH v3 08/22] objtool: Introduce STATIC_CHECK madvenka
2023-02-02 7:40 ` [RFC PATCH v3 09/22] objtool: arm64: Add basic definitions and compile madvenka
2023-02-02 7:40 ` [RFC PATCH v3 10/22] objtool: arm64: Implement decoder for Dynamic FP validation madvenka
2023-02-02 7:40 ` [RFC PATCH v3 11/22] objtool: arm64: Invoke the decoder madvenka
2023-02-02 7:40 ` [RFC PATCH v3 12/22] objtool: arm64: Compute destinations for call and jump instructions madvenka
2023-02-02 7:40 ` [RFC PATCH v3 13/22] objtool: arm64: Walk instructions and compute CFI for each instruction madvenka
2023-02-02 7:40 ` [RFC PATCH v3 14/22] objtool: arm64: Generate ORC data from CFI for object files madvenka
2023-02-02 7:40 ` [RFC PATCH v3 15/22] objtool: arm64: Add unwind hint support madvenka
2023-02-02 7:40 ` [RFC PATCH v3 16/22] arm64: Add unwind hints to exception handlers madvenka
2023-02-02 7:40 ` [RFC PATCH v3 17/22] arm64: Add kernel and module support for ORC madvenka
2023-02-02 7:40 ` [RFC PATCH v3 18/22] arm64: Build the kernel with ORC information madvenka
2023-02-10 7:52 ` Tomohiro Misono (Fujitsu)
2023-02-11 4:34 ` Madhavan T. Venkataraman
2023-02-02 7:40 ` [RFC PATCH v3 19/22] arm64: unwinder: Add a reliability check in the unwinder based on ORC madvenka
2023-02-23 4:07 ` Suraj Jitindar Singh
2023-03-06 16:52 ` Madhavan T. Venkataraman
2023-02-02 7:40 ` [RFC PATCH v3 20/22] arm64: Define HAVE_DYNAMIC_FTRACE_WITH_ARGS madvenka
2023-02-02 7:40 ` [RFC PATCH v3 21/22] arm64: Define TIF_PATCH_PENDING for livepatch madvenka
2023-02-02 7:40 ` [RFC PATCH v3 22/22] arm64: Enable livepatch for ARM64 madvenka
2023-03-01 3:12 ` [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Tomohiro Misono (Fujitsu)
2023-03-02 16:23 ` Petr Mladek
2023-03-03 9:40 ` Tomohiro Misono (Fujitsu)
2023-03-06 16:58 ` Madhavan T. Venkataraman
2023-03-06 16:57 ` Madhavan T. Venkataraman
2023-03-23 17:17 ` Mark Rutland
2023-04-08 3:40 ` Madhavan T. Venkataraman
2023-04-11 13:25 ` Mark Rutland
2023-04-12 4:17 ` Josh Poimboeuf
2023-04-12 4:48 ` Madhavan T. Venkataraman
2023-04-12 4:50 ` Madhavan T. Venkataraman
2023-04-12 5:01 ` Josh Poimboeuf
2023-04-12 14:50 ` Madhavan T. Venkataraman
2023-04-12 15:52 ` Josh Poimboeuf
2023-04-13 14:59 ` Madhavan T. Venkataraman [this message]
2023-04-13 16:30 ` Josh Poimboeuf
2023-04-15 4:27 ` Madhavan T. Venkataraman
2023-04-15 5:05 ` Josh Poimboeuf
2023-04-15 16:15 ` Madhavan T. Venkataraman
2023-04-16 8:21 ` Indu Bhagat
2023-04-13 17:04 ` Nick Desaulniers
2023-04-13 18:15 ` Jose E. Marchesi
2023-04-15 4:14 ` Madhavan T. Venkataraman
2023-12-14 20:49 ` ARM64 Livepatch based on SFrame Madhavan T. Venkataraman
2023-12-15 13:04 ` Mark Rutland
2023-12-15 15:15 ` Madhavan T. Venkataraman
[not found] <CADBMgpxQ+oM_TrtKRiREcZoZSk=AfenV_bqOk_Vt-Ov5FPHMvw@mail.gmail.com>
2023-04-08 3:41 ` [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation 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=cf583799-1a8d-4dd2-8bc7-c8fbb07f29ab@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@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).