From: Puranjay Mohan <puranjay@kernel.org>
To: Indu Bhagat <indu.bhagat@oracle.com>, Song Liu <song@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Weinan Liu <wnliu@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
roman.gushchin@linux.dev, Will Deacon <will@kernel.org>,
Ian Rogers <irogers@google.com>,
linux-toolchains@vger.kernel.org, linux-kernel@vger.kernel.org,
live-patching@vger.kernel.org, joe.lawrence@redhat.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/8] unwind, arm64: add sframe unwinder for kernel
Date: Fri, 14 Feb 2025 07:57:47 +0000 [thread overview]
Message-ID: <mb61pa5apc610.fsf@kernel.org> (raw)
In-Reply-To: <3069bb9c-6245-4754-a187-ac8253103d32@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 3597 bytes --]
Indu Bhagat <indu.bhagat@oracle.com> writes:
> On 2/12/25 11:25 PM, Song Liu wrote:
>> On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>>>
>>> On Wed, Feb 12, 2025 at 06:36:04PM -0800, Song Liu wrote:
>>>>>> [ 81.261748] copy_process+0xfdc/0xfd58 [livepatch_special_static]
>>>>>
>>>>> Does that copy_process+0xfdc/0xfd58 resolve to this line in
>>>>> copy_process()?
>>>>>
>>>>> refcount_inc(¤t->signal->sigcnt);
>>>>>
>>>>> Maybe the klp rela reference to 'current' is bogus, or resolving to the
>>>>> wrong address somehow?
>>>>
>>>> It resolves the following line.
>>>>
>>>> p->signal->tty = tty_kref_get(current->signal->tty);
>>>>
>>>> I am not quite sure how 'current' should be resolved.
>>>
>>> Hm, on arm64 it looks like the value of 'current' is stored in the
>>> SP_EL0 register. So I guess that shouldn't need any relocations.
>>>
>>>> The size of copy_process (0xfd58) is wrong. It is only about
>>>> 5.5kB in size. Also, the copy_process function in the .ko file
>>>> looks very broken. I will try a few more things.
>>
>> When I try each step of kpatch-build, the copy_process function
>> looks reasonable (according to gdb-disassemble) in fork.o and
>> output.o. However, copy_process looks weird in livepatch-special-static.o,
>> which is generated by ld:
>>
>> ld -EL -maarch64linux -z norelro -z noexecstack
>> --no-warn-rwx-segments -T ././kpatch.lds -r -o
>> livepatch-special-static.o ./patch-hook.o ./output.o
>>
>> I have attached these files to the email. I am not sure whether
>> the email server will let them through.
>>
>> Indu, does this look like an issue with ld?
>>
>
> Sorry for the delay.
>
> Looks like there has been progress since and issue may be elsewhere, but:
>
> FWIW, I looked at the .sframe and .rela.sframe sections here, the data
> does look OK. I noted that there is no .sframe for copy_process () in
> output.o... I will take a look into it.
Hi Indu,
I saw another issue in my kernel build with sframes enabled (-Wa,--gsframe):
ld: warning: orphan section `.init.sframe' from `arch/arm64/kernel/pi/lib-fdt.pi.o' being placed in section `.init.sframe'
[... Many more similar warnings (.init.sframe) ...]
So, this orphan sections is generated in the build process.
I am using GNU ld version 2.41-50 and gcc (GCC) 11.4.1
Is this section needed for sframes to work? or can we discard
.init.sframe section with a patch like following to the linker script:
-- 8< --
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 6a437bd08..8e704c0a6 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -1044,9 +1044,16 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
# define SANITIZER_DISCARDS
#endif
+#if defined(CONFIG_SFRAME_UNWIND_TABLE)
+#define DISCARD_INIT_SFRAME *(.init.sframe)
+#else
+#define DISCARD_INIT_SFRAME
+#endif
+
#define COMMON_DISCARDS \
SANITIZER_DISCARDS \
PATCHABLE_DISCARDS \
+ DISCARD_INIT_SFRAME \
*(.discard) \
*(.discard.*) \
*(.export_symbol) \
-- >8 --
Thanks,
Puranjay
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]
next prev parent reply other threads:[~2025-02-14 7:59 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 21:33 [PATCH 0/8] unwind, arm64: add sframe unwinder for kernel Weinan Liu
2025-01-27 21:33 ` [PATCH 1/8] unwind: build kernel with sframe info Weinan Liu
2025-01-30 9:45 ` Prasanna Kumar T S M
2025-02-05 0:22 ` Indu Bhagat
2025-02-07 18:01 ` Josh Poimboeuf
2025-01-27 21:33 ` [PATCH 2/8] arm64: entry: add unwind info for various kernel entries Weinan Liu
2025-01-27 21:33 ` [PATCH 3/8] unwind: add sframe v2 header Weinan Liu
2025-01-30 9:53 ` Prasanna Kumar T S M
2025-02-07 18:05 ` Josh Poimboeuf
2025-01-27 21:33 ` [PATCH 4/8] unwind: Implement generic sframe unwinder library Weinan Liu
2025-01-30 10:22 ` Prasanna Kumar T S M
2025-01-30 10:29 ` Prasanna Kumar T S M
2025-02-02 6:27 ` Weinan Liu
2025-02-02 6:37 ` Weinan Liu
2025-01-27 21:33 ` [PATCH 5/8] unwind: arm64: Add sframe unwinder on arm64 Weinan Liu
2025-01-30 10:34 ` Prasanna Kumar T S M
2025-01-27 21:33 ` [PATCH 6/8] unwind: arm64: add reliable stacktrace support for arm64 Weinan Liu
2025-01-30 10:36 ` Prasanna Kumar T S M
2025-01-27 21:33 ` [PATCH 7/8] arm64: Define TIF_PATCH_PENDING for livepatch Weinan Liu
2025-01-30 9:54 ` Prasanna Kumar T S M
2025-02-27 12:10 ` Miroslav Benes
2025-01-27 21:33 ` [PATCH 8/8] arm64: Enable livepatch for ARM64 Weinan Liu
2025-01-30 9:55 ` Prasanna Kumar T S M
2025-01-31 16:08 ` Prasanna Kumar T S M
2025-02-03 15:16 ` Steven Rostedt
2025-01-28 15:35 ` [PATCH 0/8] unwind, arm64: add sframe unwinder for kernel Indu Bhagat
2025-01-29 7:23 ` Weinan Liu
2025-01-30 17:59 ` Song Liu
2025-01-30 18:34 ` Song Liu
2025-01-30 19:01 ` Roman Gushchin
2025-01-30 19:18 ` Song Liu
2025-02-04 14:49 ` Puranjay Mohan
2025-02-04 23:52 ` Puranjay Mohan
2025-02-06 15:02 ` Weinan Liu
2025-02-07 12:16 ` Puranjay Mohan
2025-02-07 17:52 ` Josh Poimboeuf
2025-02-10 8:30 ` Weinan Liu
2025-02-25 1:02 ` Weinan Liu
2025-02-25 18:13 ` Josh Poimboeuf
2025-02-25 23:01 ` Weinan Liu
2025-02-25 19:38 ` Indu Bhagat
2025-02-25 23:54 ` Weinan Liu
2025-02-26 0:22 ` Indu Bhagat
2025-02-26 10:23 ` Puranjay Mohan
2025-02-26 17:40 ` Indu Bhagat
2025-02-27 9:38 ` Puranjay Mohan
2025-02-28 6:47 ` Indu Bhagat
2025-03-09 14:43 ` Indu Bhagat
2025-02-12 23:32 ` Song Liu
2025-02-12 23:49 ` Josh Poimboeuf
2025-02-13 2:36 ` Song Liu
2025-02-13 2:45 ` Josh Poimboeuf
[not found] ` <CAPhsuW4iDuTBfZowJRhxLFyK=g=s+-pK2Eq4+SNj9uL99eNkmw@mail.gmail.com>
2025-02-13 7:46 ` Puranjay Mohan
2025-02-13 19:40 ` Song Liu
2025-02-14 8:08 ` Josh Poimboeuf
[not found] ` <CAPhsuW6dxPtgqZaHrZEVhQXwm2+sETreZnGybZXVKYKfG9H6tg@mail.gmail.com>
2025-02-14 19:34 ` Josh Poimboeuf
2025-02-14 22:04 ` Song Liu
2025-02-14 22:33 ` Josh Poimboeuf
2025-02-14 23:23 ` Josh Poimboeuf
2025-02-18 4:38 ` Song Liu
2025-02-18 6:37 ` Josh Poimboeuf
2025-02-18 18:20 ` Song Liu
2025-02-18 18:40 ` Josh Poimboeuf
2025-02-19 17:44 ` Song Liu
[not found] ` <CAPhsuW57xpR1YZqENvDr0vNZGVrq4+LUzPRA-wZipurTTy7MmA@mail.gmail.com>
2025-02-20 18:22 ` Josh Poimboeuf
[not found] ` <CAPhsuW53DK2vFH-BZeUYN-eythX3NQEbcxrYf6jvBDtDmctRgw@mail.gmail.com>
2025-02-25 0:13 ` Song Liu
2025-02-13 23:22 ` Indu Bhagat
2025-02-13 23:47 ` Song Liu
2025-02-14 7:57 ` Puranjay Mohan [this message]
2025-02-14 17:39 ` Indu Bhagat
2025-02-14 18:41 ` Indu Bhagat
2025-02-14 18:58 ` Puranjay Mohan
2025-02-14 19:38 ` Josh Poimboeuf
2025-02-14 19:42 ` Josh Poimboeuf
2025-02-13 0:09 ` Indu Bhagat
2025-02-13 2:40 ` Song Liu
2025-02-13 2:52 ` Josh Poimboeuf
2025-02-13 7:26 ` Puranjay Mohan
2025-02-13 7:37 ` Song Liu
2025-02-13 7:53 ` Puranjay Mohan
2025-02-13 19:42 ` Song Liu
2025-02-13 8:37 ` Puranjay Mohan
2025-02-13 20:46 ` Song Liu
2025-02-13 22:21 ` Puranjay Mohan
2025-02-13 23:34 ` Song Liu
2025-02-14 1:58 ` Song Liu
2025-02-14 8:56 ` Puranjay Mohan
2025-02-14 18:10 ` Song Liu
2025-02-14 18:24 ` Josh Poimboeuf
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=mb61pa5apc610.fsf@kernel.org \
--to=puranjay@kernel.org \
--cc=indu.bhagat@oracle.com \
--cc=irogers@google.com \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=song@kernel.org \
--cc=will@kernel.org \
--cc=wnliu@google.com \
/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).