Skip to content

Conversation

@sjenning
Copy link
Contributor

The original logic in the inclusion tree code worked under the
assumption that it was the only code path marking symbols for inclusion.
Therefore, if the symbol had been marked as included, it could be safely
assumed that we also already called kpatch_include_symbol() on it. With
the special section handling marking symbols as included, however, this
assumption is not valid.

We should call kpatch_include_symbol() regardless of whether or not the
symbol has already been marked as included or not in order to possible
include the symbol's entire bundle.

Signed-off-by: Seth Jennings sjenning@redhat.com

The original logic in the inclusion tree code worked under the
assumption that it was the only code path marking symbols for inclusion.
Therefore, if the symbol had been marked as included, it could be safely
assumed that we also already called kpatch_include_symbol() on it.  With
the special section handling marking symbols as included, however, this
assumption is not valid.

We should call kpatch_include_symbol() regardless of whether or not the
symbol has already been marked as included or not in order to possible
include the symbol's entire bundle.

Signed-off-by: Seth Jennings <sjenning@redhat.com>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand this right, does this mean we can remove the "rela->sym->include = 1" lines in kpatch_regenerate_special_section and kpatch_process_special_sections?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My brain is about done for today. I don't think that is right since there could be some symbols in the rela group that are not reachable from a changed function, but are still need for the rela group to resolve.

Just for kicks I did remove the include line from kpatch_regenerate_special_section() and it fail integration. Don't know why. Logs didn't say.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I think that makes sense.

@jpoimboe
Copy link
Member

Getting an integration test failure due to a create-diff-object seg fault. Looks like infinite recursion:

Core was generated by `/home/jpoimboe/git/kpatch/kpatch-build/create-diff-object orig/net/core/dev.o p'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000403f06 in kpatch_include_symbol (sym=<error reading variable: Cannot access memory at address 0x7fffea841ff8>, 
    recurselevel=<error reading variable: Cannot access memory at address 0x7fffea841ff4>) at create-diff-object.c:939
939 {
Missing separate debuginfos, use: debuginfo-install elfutils-libelf-0.158-3.fc20.x86_64
(gdb) bt
#0  0x0000000000403f06 in kpatch_include_symbol (sym=<error reading variable: Cannot access memory at address 0x7fffea841ff8>, 
    recurselevel=<error reading variable: Cannot access memory at address 0x7fffea841ff4>) at create-diff-object.c:939
#1  0x00000000004040d6 in kpatch_include_symbol (sym=0x1c9c930, recurselevel=130973) at create-diff-object.c:965
#2  0x00000000004040d6 in kpatch_include_symbol (sym=0x1c9c930, recurselevel=130972) at create-diff-object.c:965
#3  0x00000000004040d6 in kpatch_include_symbol (sym=0x1c9c930, recurselevel=130971) at create-diff-object.c:965
....
(gdb) p *sym
$8 = {list = {next = 0x1c9c990, prev = 0x1c9c8d0}, twin = 0x1a2ad60, sec = 0x1c75630, sym = {st_name = 6637, st_info = 18 '\022', st_other = 0 '\000', st_shndx = 83, 
    st_value = 0, st_size = 153}, name = 0x7fd0341a49f5 <error: Cannot access memory at address 0x7fd0341a49f5>, index = 647, bind = 1 '\001', type = 2 '\002', 
  status = CHANGED, {include = 1, strip = 1}}
(gdb) p *sym->sec
$12 = {list = {next = 0x1c756d0, prev = 0x1c75590}, twin = 0x1a03a60, sh = {sh_name = 1321, sh_type = 1, sh_flags = 6, sh_addr = 0, sh_offset = 7712, sh_size = 153, 
    sh_link = 0, sh_info = 0, sh_addralign = 16, sh_entsize = 0}, data = 0x1c56860, name = 0x7fd03418f7c9 <error: Cannot access memory at address 0x7fd03418f7c9>, index = 83, 
  status = CHANGED, include = 1, {{base = 0x1c756d0, relas = {next = 0x1c8ea70, prev = 0x1c9c930}}, {rela = 0x1c756d0, secsym = 0x1c8ea70, sym = 0x1c9c930}}}

@sjenning
Copy link
Contributor Author

I knew I had that check in there for some reason!
On Jun 26, 2014 10:03 PM, "Josh Poimboeuf" notifications@github.com wrote:

Getting an integration test failure due to a create-diff-object seg fault.
Looks like infinite recursion:

Core was generated by `/home/jpoimboe/git/kpatch/kpatch-build/create-diff-object orig/net/core/dev.o p'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000403f06 in kpatch_include_symbol (sym=<error reading variable: Cannot access memory at address 0x7fffea841ff8>,
recurselevel=<error reading variable: Cannot access memory at address 0x7fffea841ff4>) at create-diff-object.c:939
939 {
Missing separate debuginfos, use: debuginfo-install elfutils-libelf-0.158-3.fc20.x86_64
(gdb) bt
#0 0x0000000000403f06 in kpatch_include_symbol (sym=<error reading variable: Cannot access memory at address 0x7fffea841ff8>,
recurselevel=<error reading variable: Cannot access memory at address 0x7fffea841ff4>) at create-diff-object.c:939
#1 0x00000000004040d6 in kpatch_include_symbol (sym=0x1c9c930, recurselevel=130973) at create-diff-object.c:965
#2 0x00000000004040d6 in kpatch_include_symbol (sym=0x1c9c930, recurselevel=130972) at create-diff-object.c:965
#3 0x00000000004040d6 in kpatch_include_symbol (sym=0x1c9c930, recurselevel=130971) at create-diff-object.c:965
....
(gdb) p *sym
$8 = {list = {next = 0x1c9c990, prev = 0x1c9c8d0}, twin = 0x1a2ad60, sec = 0x1c75630, sym = {st_name = 6637, st_info = 18 '\022', st_other = 0 '\000', st_shndx = 83,
st_value = 0, st_size = 153}, name = 0x7fd0341a49f5 <error: Cannot access memory at address 0x7fd0341a49f5>, index = 647, bind = 1 '\001', type = 2 '\002',
status = CHANGED, {include = 1, strip = 1}}
(gdb) p *sym->sec
$12 = {list = {next = 0x1c756d0, prev = 0x1c75590}, twin = 0x1a03a60, sh = {sh_name = 1321, sh_type = 1, sh_flags = 6, sh_addr = 0, sh_offset = 7712, sh_size = 153,
sh_link = 0, sh_info = 0, sh_addralign = 16, sh_entsize = 0}, data = 0x1c56860, name = 0x7fd03418f7c9 <error: Cannot access memory at address 0x7fd03418f7c9>, index = 83,
status = CHANGED, include = 1, {{base = 0x1c756d0, relas = {next = 0x1c8ea70, prev = 0x1c9c930}}, {rela = 0x1c756d0, secsym = 0x1c8ea70, sym = 0x1c9c930}}}


Reply to this email directly or view it on GitHub
#270 (comment).

@sjenning sjenning closed this Jun 27, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants