On 2/13/25 11:57 PM, Puranjay Mohan wrote:
Indu Bhagat <indu.bha...@oracle.com> writes:
On 2/12/25 11:25 PM, Song Liu wrote:
On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf <jpoim...@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
No this should not be discarded. This looks like a wrongly-named but
valid SFrame section.
Once correctly named as .sframe, the linker should do the right thing.
Let me check whats going on..
.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
