<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Josh,<br><br></div>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).</div><div dir="ltr"><br></div><div dir="ltr">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.<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 17, 2018 at 7:13 AM Josh Poimboeuf <<a href="mailto:jpoimboe@redhat.com">jpoimboe@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Oct 16, 2018 at 04:37:32PM -0700, Paul Dagnelie wrote:<br>
> Hello!<br>
> I'm trying to see if I can use kpatch to apply patches to an out-of-tree<br>
> module, specifically zfs.ko. I've managed to make some progress by tweaking<br>
> kpatch-build to clone the appropriate source tree, do the initial and<br>
> patched build, and the process gets most of the way. I even made a couple<br>
> small tweaks to create-diff-object to get it to ignore changes made to a<br>
> special symbol that gets updated to the current git rev on build.<br>
> <br>
> However, I'm running into an issue with create-diff-object. I've looked<br>
> into it, and it looks like the specific issue is that when the initial<br>
> build of dmu_send.o is done, a specific function (setup_to_thread) doesn't<br>
> get its name mangled by gcc, but when we rebuild with the patch applied, it<br>
> becomes setup_to_thread.constprop.20. I've compared the gcc commands to<br>
> create the two, and I think they're identical.<br>
> <br>
> I was wondering if this is a problem that has been seen and worked around<br>
> before, either for in-tree modules or in other experiments people have done<br>
> with out-of-tree modules. Any advice, ideas, or pointers would be greatly<br>
> appreciated.<br>
<br>
Hi Paul,<br>
<br>
The constprop suffix is a common source of kpatch headaches.  It's a GCC<br>
optimization which modifies a function's calling interface.  Your patch<br>
probably changed the code such that each of setup_to_thread's callers<br>
passes the same constant as one of it's arguments, causing GCC to remove<br>
the argument and instead hard-code the constant inside the function.<br>
<br>
In theory create-diff-object is supposed to be able to handle that<br>
situation.  What error are you seeing?  Can you open an issue on github<br>
with the original and patched .o files attached?<br>
<br>
BTW, if you have any improvements in tooling or documentation that would<br>
make patching out-of-tree modules easier, a pull request would be<br>
appreciated.  Thanks!<br>
<br>
-- <br>
Josh<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Paul Dagnelie<br></div></div>