On Fri, Feb 14, 2025 at 12:08 AM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> 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:
livepatch-special-static.ko
Description: Binary data
