All of lore.kernel.org
 help / color / mirror / Atom feed
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 05/20] objtool: Reorganize ORC types
Date: Sun, 29 May 2022 10:36:30 -0500	[thread overview]
Message-ID: <c42112ac-5606-347f-dfe7-ef941b77c6a5@linux.microsoft.com> (raw)
In-Reply-To: <ab3533a6-cb60-b553-e140-40b87fc09428@huawei.com>

See my responses inline...

On 5/24/22 09:27, Chen Zhongjin wrote:
> 
> 
> On 2022/5/24 8:16, madvenka@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
>>
>> The ORC code needs to be reorganized into arch-specific and generic parts
>> so that architectures other than X86 can use the generic parts.
>>
>> orc_types.h contains the following ORC definitions shared between objtool
>> and the kernel:
>>
>> 	- ORC register definitions which are arch-specific.
>> 	- orc_entry structure which is generic.
> ...
>> diff --git a/include/linux/orc_entry.h b/include/linux/orc_entry.h
>> new file mode 100644
>> index 000000000000..3d49e3b9dabe
>> --- /dev/null
>> +++ b/include/linux/orc_entry.h
>> @@ -0,0 +1,39 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * Copyright (C) 2017 Josh Poimboeuf <jpoimboe@redhat.com>
>> + */
>> +
>> +#ifndef _ORC_ENTRY_H
>> +#define _ORC_ENTRY_H
>> +
>> +#ifndef __ASSEMBLY__
>> +#include <asm/byteorder.h>
>> +
>> +/*
>> + * This struct is more or less a vastly simplified version of the DWARF Call
>> + * Frame Information standard.  It contains only the necessary parts of DWARF
>> + * CFI, simplified for ease of access by the in-kernel unwinder.  It tells the
>> + * unwinder how to find the previous SP and BP (and sometimes entry regs) on
>> + * the stack for a given code address.  Each instance of the struct corresponds
>> + * to one or more code locations.
>> + */
>> +struct orc_entry {
>> +	s16		sp_offset;
>> +	s16		fp_offset;
>> +#if defined(__LITTLE_ENDIAN_BITFIELD)
>> +	unsigned	sp_reg:4;
>> +	unsigned	fp_reg:4;
> Are sp_reg & fp_reg & end needed? I noticed that they are not used in
> reliability checking.

Yeah. The ORC entry structure is a superset of what I need for ARM64. But X86 requires all of it.
(Although I think "end" is not needed anymore).

And, other architectures might require all of it. So, I am keeping it as is.

> 
>> +	unsigned	type:3;
>> +	unsigned	end:1;
>> +#elif defined(__BIG_ENDIAN_BITFIELD)
>> +	unsigned	fp_reg:4;
>> +	unsigned	sp_reg:4;
>> +	unsigned	unused:4;
>> +	unsigned	end:1;
>> +	unsigned	type:3;
>> +#endif
>> +} __packed;
>> +
>> +#endif /* __ASSEMBLY__ */
>> +
>> +#endif /* _ORC_ENTRY_H */

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 05/20] objtool: Reorganize ORC types
Date: Sun, 29 May 2022 10:36:30 -0500	[thread overview]
Message-ID: <c42112ac-5606-347f-dfe7-ef941b77c6a5@linux.microsoft.com> (raw)
In-Reply-To: <ab3533a6-cb60-b553-e140-40b87fc09428@huawei.com>

See my responses inline...

On 5/24/22 09:27, Chen Zhongjin wrote:
> 
> 
> On 2022/5/24 8:16, madvenka@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
>>
>> The ORC code needs to be reorganized into arch-specific and generic parts
>> so that architectures other than X86 can use the generic parts.
>>
>> orc_types.h contains the following ORC definitions shared between objtool
>> and the kernel:
>>
>> 	- ORC register definitions which are arch-specific.
>> 	- orc_entry structure which is generic.
> ...
>> diff --git a/include/linux/orc_entry.h b/include/linux/orc_entry.h
>> new file mode 100644
>> index 000000000000..3d49e3b9dabe
>> --- /dev/null
>> +++ b/include/linux/orc_entry.h
>> @@ -0,0 +1,39 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * Copyright (C) 2017 Josh Poimboeuf <jpoimboe@redhat.com>
>> + */
>> +
>> +#ifndef _ORC_ENTRY_H
>> +#define _ORC_ENTRY_H
>> +
>> +#ifndef __ASSEMBLY__
>> +#include <asm/byteorder.h>
>> +
>> +/*
>> + * This struct is more or less a vastly simplified version of the DWARF Call
>> + * Frame Information standard.  It contains only the necessary parts of DWARF
>> + * CFI, simplified for ease of access by the in-kernel unwinder.  It tells the
>> + * unwinder how to find the previous SP and BP (and sometimes entry regs) on
>> + * the stack for a given code address.  Each instance of the struct corresponds
>> + * to one or more code locations.
>> + */
>> +struct orc_entry {
>> +	s16		sp_offset;
>> +	s16		fp_offset;
>> +#if defined(__LITTLE_ENDIAN_BITFIELD)
>> +	unsigned	sp_reg:4;
>> +	unsigned	fp_reg:4;
> Are sp_reg & fp_reg & end needed? I noticed that they are not used in
> reliability checking.

Yeah. The ORC entry structure is a superset of what I need for ARM64. But X86 requires all of it.
(Although I think "end" is not needed anymore).

And, other architectures might require all of it. So, I am keeping it as is.

> 
>> +	unsigned	type:3;
>> +	unsigned	end:1;
>> +#elif defined(__BIG_ENDIAN_BITFIELD)
>> +	unsigned	fp_reg:4;
>> +	unsigned	sp_reg:4;
>> +	unsigned	unused:4;
>> +	unsigned	end:1;
>> +	unsigned	type:3;
>> +#endif
>> +} __packed;
>> +
>> +#endif /* __ASSEMBLY__ */
>> +
>> +#endif /* _ORC_ENTRY_H */

Thanks!

Madhavan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-05-29 15:36 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 [this message]
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
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=c42112ac-5606-347f-dfe7-ef941b77c6a5@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.