Hi Josh, I can file an issue on github with the .o files. The patch I'm testing with does indeed cause a particular argument to always be 0. The specific error message is 'create-diff-object: ERROR: dmu_send.o: find_local_syms: 178: find_local_syms for dmu_send.c: couldn't find in vmlinux symbol table'. As for why create-diff-object didn't handle the error, it looks like the error happened in find_local_syms because locals_match failed, and find_local_syms was called from lookup_open, which is called before kpatch_rename_mangled_functions (which appears to be the function that handles the .constprop renaming).
As for the changes to the tooling to get it to build an out-of-tree module... frankly what I've done is a pretty big pile of gross hacks. It may be possible to clean it up some, which I would want to do for maintainability purposes anyway. If I come up with something that others might find useful, I'll be sure to open a PR. On Wed, Oct 17, 2018 at 7:13 AM Josh Poimboeuf <[email protected]> wrote: > On Tue, Oct 16, 2018 at 04:37:32PM -0700, Paul Dagnelie wrote: > > Hello! > > I'm trying to see if I can use kpatch to apply patches to an out-of-tree > > module, specifically zfs.ko. I've managed to make some progress by > tweaking > > kpatch-build to clone the appropriate source tree, do the initial and > > patched build, and the process gets most of the way. I even made a couple > > small tweaks to create-diff-object to get it to ignore changes made to a > > special symbol that gets updated to the current git rev on build. > > > > However, I'm running into an issue with create-diff-object. I've looked > > into it, and it looks like the specific issue is that when the initial > > build of dmu_send.o is done, a specific function (setup_to_thread) > doesn't > > get its name mangled by gcc, but when we rebuild with the patch applied, > it > > becomes setup_to_thread.constprop.20. I've compared the gcc commands to > > create the two, and I think they're identical. > > > > I was wondering if this is a problem that has been seen and worked around > > before, either for in-tree modules or in other experiments people have > done > > with out-of-tree modules. Any advice, ideas, or pointers would be greatly > > appreciated. > > Hi Paul, > > The constprop suffix is a common source of kpatch headaches. It's a GCC > optimization which modifies a function's calling interface. Your patch > probably changed the code such that each of setup_to_thread's callers > passes the same constant as one of it's arguments, causing GCC to remove > the argument and instead hard-code the constant inside the function. > > In theory create-diff-object is supposed to be able to handle that > situation. What error are you seeing? Can you open an issue on github > with the original and patched .o files attached? > > BTW, if you have any improvements in tooling or documentation that would > make patching out-of-tree modules easier, a pull request would be > appreciated. Thanks! > > -- > Josh > -- Paul Dagnelie
_______________________________________________ kpatch mailing list [email protected] https://www.redhat.com/mailman/listinfo/kpatch
