Re: [PATCH 0/8] unwind, arm64: add sframe unwinder for kernel
Song Liu <[email protected]>
| Newsgroups | org.kernel.vger.linux-toolchains,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.live-patching |
|---|---|
| Message-ID | <CAPhsuW6q+yhn0pGQb0K+RhXHYDkjEgomZ2pu3P_MEeX+xNRe0g@mail.gmail.com> |
Hi Josh, On Fri, Feb 14, 2025 at 11:34 AM Josh Poimboeuf <[email protected]> wrote: > > On Fri, Feb 14, 2025 at 09:51:41AM -0800, Song Liu wrote: > > > Ignorant arm64 question: is the module's text further away from slab > > > memory than vmlinux text, thus requiring a different instruction (or > > > GOT/TOC) to access memory further away in the address space? > > > > It appears to me the module text is very close to vmlinux text: > > > > vmlinux: ffff8000800b4b68 T copy_process > > module: ffff80007b0f06d0 t copy_process [livepatch_always_inline_special_static] > > Hm... the only other thing I can think of is that the klp relas might be > wrong somewhere. If you share patched.o and .ko files from the same > build I could take a look. A tarball with these files is available here: https://drive.google.com/file/d/1ONB1tC9oK-Z5ShmSXneqWLTjJgC5Xq-C/view?usp=drive_link > BTW, I realized the wrong function size shown in the WARNING stack trace > is probably just due to a kallsyms quirk. It calculates a symbol's size > by subtracting its start address from the next symbol's start address. > It doesn't actually use the ELF symbol size. So the next symbol after > copy_process() in the loaded module's address space might just be far > away. Yeah, I also think kallsyms logic was the issue here. So it is not the same as the gdb-disassembly issue. > That kallsyms issue has caused other headaches. It really needs to be > fixed to use the actual ELF symbol size. Maybe we should have a "module_text_end" symbol? Thanks, Song