Re: [PATCH 0/8] unwind, arm64: add sframe unwinder for kernel

Song Liu
2025-02-14T17:51:54Z

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

On Fri, Feb 14, 2025 at 12:08 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Thu, Feb 13, 2025 at 11:40:43AM -0800, Song Liu wrote:
> > Yeah, objdump does show the same disassembly. However, if
> > I open the file with gdb, and do "disassemble copy_process",
> > the one in livepatch-special-static.o looks very weird.
>
> The symbol table looks ok. I'm not sure why gdb is getting confused,
> but that could possibly be a red herring. Maybe it doesn't like the
> -ffunction-sections for some reason.
>
> It's really weird the function length reported by kallsyms is so wrong.
> Can you share the .ko?

Attached is the .ko file.

>
> The refcount warning might indicate it's passing some bogus memory to
> tty_kref_get(). Any chance you have struct randomization enabled?

No, struct randomization is disabled.

> Are you sure there's no code or .config mismatch between the built
> kernel and the running kernel?

The test is done in a vm, so the .config used to build the livepatch is
exactly the same as the testing kernel .

>
> 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]

I run tests with CONFIG_PAGE_SIZE_64KB=y.

Thanks,
Song

[-- Attachment #2: livepatch-special-static.ko --]
[-- Type: application/octet-stream, Size: 1550608 bytes --]