.lib_exports.o: No such file or directory

[joe-lawrence]

Building meminfo-cmdline-rebuild-SLOW.patch against an upstream 4.10 kernel tree, I get the following error:

% kpatch-build --skip-cleanup -s /root/linux fedora-25/meminfo-cmdline-rebuild-SLOW.patch
Skipping cleanup
Using source directory at /root/linux
Testing patch file
checking file fs/proc/cmdline.c
checking file fs/proc/meminfo.c
checking file include/linux/kernel.h
Reading special section data
Building original kernel
Building patched kernel
cp: cannot stat '/root/.kpatch/obj/lib/.lib_exports.o': No such file or directory
ERROR: kpatch build failed. Check /root/.kpatch/build.log for more details.

That file is listed in the changed objects file, but doesn't exist when kpatch-build tries to make copies.

% grep '\.lib_exports.o' /root/.kpatch/tmp/changed_objs 
lib/.lib_exports.o
arch/x86/lib/.lib_exports.o
% find /root/.kpatch/ -name .lib_exports.o
(nothing)

[joe-lawrence]

Note that .lib_exports.o was added in upstream kernel commit: 7f2084fa55e6 [kbuild] handle exports in lib-y objects reliably (v4.9+).

[joe-lawrence]

Adding a */.lib_exports.o pattern to the kpatch-gcc ignore list renders a kpatch .ko that loads and does its thing. My reading of the kernel patch is that .lib_exports.o is only created for lib.a files and that patching lib-y objects is not supported by kpatch... Is that correct @jpoimboe ? (I tried patching lib/string.c for example, and create-diff-object complains that it has no fentry call.)

[flaming-toast]

According to upstream commit 9da2f584b54 .lib_exports.o is an empty dummy object used with a linker script to create lib-ksyms.o, and it gets removed afterwards, so we see that No such file or directory error when kpatch-build tries to cp it. Since this is an empty object used only for an intermediate step, it shouldn't even show up on changed_objs, as it does not contain any code to patch.

So I think we should include a new regex pattern in kpatch-gcc to exclude it. (And shouldn't the .*.o pattern have caught this case? Or should that pattern really be *.*.o instead?)

[joe-lawrence]

@flaming-toast

• globs - Yes, *.*.o would extend the original .*.o glob to include subdirectories, and therefore catch lib/.lib_exports.o as well. Good catch, I just tested this and will send out a PR shortly.
• lib_exports.o - we can safely ignore it to fix this issue, but what about the lib-y/lib.a question in general? Should be a documented limitation?

[flaming-toast]

@joe-lawrence Yeah, we cannot patch lib/ functions because they are simply not hookable by ftrace, and they're compiled without the -pg profiling option. See commit 2464a609ded "ftrace: do not trace library functions". And yes, it would be nice to document it somewhere :-)

[jpoimboe]

It's pretty much self-documenting, as if you try to create a patch for a lib/ function it will fail with function foo has no fentry call, unable to patch.

[joe-lawrence]

@jpoimboe - I was thinking of the Limitations section of README.md, not the kpatch-build tool.

[jpoimboe]

@joe-lawrence Yeah, that would probably be a good idea. And it should mention that any function with a missing 'fentry' call can't be patched.