-
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
kpatch_create_dynamic_rela_sections: 1563: lookup_local_symbol .data..read_mostly (dev.c) #219
Comments
I have a fix for this specific failure, but then this patch shows another failure for which I'll open a new issue:
|
jpoimboe
added a commit
to jpoimboe/kpatch
that referenced
this issue
May 29, 2014
Replace .data..read_mostly references with their corresponding symbol references. Fixes dynup#219.
jpoimboe
added a commit
to jpoimboe/kpatch
that referenced
this issue
May 30, 2014
Support patching functions which uses these sections by converting references to these sections to symbol object references. Fixes dynup#219.
jpoimboe
added a commit
to jpoimboe/kpatch
that referenced
this issue
May 30, 2014
The current approach of trying to include the tracepoint-related sections doesn't work at all. The new tracepoints don't show up in "perf list". And also, with one patch (issue dynup#219) I've seen a panic in jump_label_del_module(). I suspect it's because the kernel is confused by dynamic relocations' changing of the jump table after it was registered with the jump table code. I think the best approach for now is to just always exclude these sections. It should be harmless, with the only consequence being that tracepoints and jump labels can't be enabled in patched functions (which is already the case with the current code anyway). Fixes dynup#221.
jpoimboe
added a commit
to jpoimboe/kpatch
that referenced
this issue
May 30, 2014
The current approach of trying to include the tracepoint-related sections doesn't work at all. The new tracepoints don't show up in "perf list". And also, with one patch (issue dynup#219) I've seen a panic in jump_label_del_module(). I suspect it's because the kernel is confused by dynamic relocations' changing of the jump table after it was registered with the jump table code. I think the best approach for now is to just always exclude these sections. It should be harmless, with the only consequence being that tracepoints and jump labels can't be enabled in patched functions (which is already the case with the current code anyway). Fixes dynup#221.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm getting error with following patch for __netif_receive_skb_core:
The text was updated successfully, but these errors were encountered: