You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Handle changed section .rodata._entry.XXX not selected for inclusion #1206
I'm not sure what this error means. Maybe there could be a static local variable named "_entry" (possibly created from multiple calls to an inline function in a header file) which isn't getting properly detected somehow.
It's also not clear to me why this patch would cause tcp_skb_mark_lost_uncond_verify() to be marked as changed, though that might be explained if your code version differs from the one I'm looking at.
If you send the tcp_input.o files in ~/.kpatch/tmp/{orig,patched} directories could take a look.
I found something like the following unblocks kpatch-build. I am able to use livepatch to add printk into the kernel for debug. But I am not sure whether this is fine for official use.
The problem is that struct pi_entry _entry is a local static variable which uses the __LINE__ macro, which causes the line number to be hard-coded in the struct. So any changes above it in the source file will cause all the line numbers (and corresponding static local _entry structs) to change.
I think the fix is to add _entry to the var_names array in is_special_static(). Can you verify that fixes it?
We will also need to do a change similar to your suggested patch, for the case where a patch adds a new printk(). That will add a new entry to to .printk_index. So we should just ignore all changes to .printk_index and .rela.printk_index. I'll work on a pull request.
Activity
jpoimboe commentedon Aug 5, 2021
I'm not sure what this error means. Maybe there could be a static local variable named "_entry" (possibly created from multiple calls to an inline function in a header file) which isn't getting properly detected somehow.
It's also not clear to me why this patch would cause tcp_skb_mark_lost_uncond_verify() to be marked as changed, though that might be explained if your code version differs from the one I'm looking at.
If you send the tcp_input.o files in ~/.kpatch/tmp/{orig,patched} directories could take a look.
liu-song-6 commentedon Aug 5, 2021
tcp_input.zip
Here are the two files. Thanks!
liu-song-6 commentedon Aug 5, 2021
I just figured out it is from the prink_index work, which is in prink/for-next https://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git/tree/include/linux/printk.h?h=for-next#n377
I guess we will need to work around it in kpatch-build for 5.15. For now, I will try to fix it in the patch itself. Thanks!
jpoimboe commentedon Aug 5, 2021
Ah, good find... I'll look into how to fix kpatch-build.
liu-song-6 commentedon Aug 5, 2021
I guess we will somehow ignore it in create-diff-object. Do we need to rename it to something more clear (i.e.
__pi_entryinstead of just_entry)?liu-song-6 commentedon Aug 9, 2021
I found something like the following unblocks kpatch-build. I am able to use livepatch to add printk into the kernel for debug. But I am not sure whether this is fine for official use.
jpoimboe commentedon Aug 10, 2021
The problem is that
struct pi_entry _entryis a local static variable which uses the__LINE__macro, which causes the line number to be hard-coded in the struct. So any changes above it in the source file will cause all the line numbers (and corresponding static local _entry structs) to change.I think the fix is to add
_entryto thevar_namesarray inis_special_static(). Can you verify that fixes it?We will also need to do a change similar to your suggested patch, for the case where a patch adds a new printk(). That will add a new entry to to
.printk_index. So we should just ignore all changes to.printk_indexand.rela.printk_index. I'll work on a pull request.create-diff-object: Support CONFIG_PRINTK_INDEX, part 1
kpatch-build: Support CONFIG_PRINTK_INDEX, part 2
create-diff-object: Support CONFIG_PRINTK_INDEX, part 1
kpatch-build: Support CONFIG_PRINTK_INDEX, part 2
WIP