-
Notifications
You must be signed in to change notification settings - Fork 302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lookup: local_match can be empty #1345
Conversation
Thanks for the patch. I would rather do a more explicit check, would this patch work instead? jpoimboe@143322e |
yes |
I tried to reproduce this yesterday w/o any luck. My kernel has three cmdline.o objects:
(Edit: I later realized that vmlinux.symtab isn't the correct place to look, we should be observing the reference/patched build object file symbol tables as they may contain intermediate symbols that don't end up in vmlinux) And none of their associated cmdline.c files have any local object symbols according to ~/.kpatch/tmp/vmlinux.symtab:
I can build kpatches to either arch/x86/lib/cmdline.o and /fs/proc/cmdline.o without any issues. I had similar success with net/core/scm.c and net/unix/scm.c which only have local notype symbols... does this scenario only occur if there are no local symbols of any type (no function, object, or notype) ? |
Oh, I see Josh posted a revised version of the fix -- yes, the explicit check is much more approachable for dolts like myself :) |
Both files do not have function and object local symbol |
@lzw3232 : could you possibly attach the object files in question? I find it difficult to artificially create this scenario my kernel objects will end up with a local section symbol at the very least. |
I test in federa, kernel-6.2.15-100.fc36.src.rpm patch:
result:
|
That patch’s result: (after using my commit)
So you can use this patch for testing:
result: (before using commit)
|
Thanks for the examples, @lzw3232 , that helped me confirm that Josh's patch was not fixing my scm.c examples. Using your net/unix/scm.c patch, I wrapped it into a repro script (drop it in the cloned kpatch directory): it fails because "__kstrtab_unix_tot_inflight" and other such exported symbols are NOTYPE and LOCAL. If I modify file_has_locals() to skip STT_NOTYPE, this repro will pass. But I'm not sure how safe that is, Josh? |
I think that file_has_locals() should skip symbols which are not STT_FUNC and STT_OBJECT, just like locals_match() |
Agreed, I'll update the patch and open a new PR. |
If the file doesn't have local symbols, any empty match will do, and duplicate matching local symbol lists aren't a problem. Fixes dynup#1345. Reported-by: lzwycc <lzw32321226@163.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
If the file doesn't have local object/func symbols, any empty match will do, and duplicate matching local symbol lists aren't a problem. Fixes dynup#1345. Reported-by: lzwycc <lzw32321226@163.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
your patch was not fixing my scm.c examples. because you forget the maybe_discarded_sym. I modify my code, Could you use my PR, because it is useful for me. |
If the file doesn't have local object/func symbols, any empty match will do, and duplicate matching local symbol lists aren't a problem. Signed-off-by: lzw3232 <lzw32321226@163.com>
If the file doesn't have local object/func symbols, any empty match will do, and duplicate matching local symbol lists aren't a problem. Fixes dynup#1345. Reported-by: lzwycc <lzw32321226@163.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
symtab may have two STT_FILE symbols with the same name, but neither of them has a local symbol.
we can choose either one,
because the lookup_table_file_sym is used to match the local symbol.
for example:
in x86:
arch/x86/mm/kaslr.c have two local symbols (can modify the code to have no local symbols)
arch/x86/lib/kaslr.c have no local symbols
if we make the patch for arch/x86/lib/kaslr.c or arch/x86/mm/kaslr.c, it will be error.