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
@ryanbsull noticed this when building a CVE-2023-35788 kpatch for some releases of RHEL on ppc64le:
ERROR: cls_flower.o: reference to static local variable __msg.59123 in fl_set_geneve_opt was removed
Which is interesting given the patch only adds a small conditional to fl_set_geneve_opt().
When comparing the original cls_flower.o to the patched cls_flower.o, it seems that the compiler has converted fl_set_geneve_opt() from a function to an inlined one (thanks -O3 optimization). In order to debug this, we looked at the symbol tables for each object file and compared them -- an equal number of __msg. variables, but no fl_set_geneve_opt symbol in the patched object.
Modifying the kpatch to mark fl_set_geneve_opt as noinline avoided the build error, but perhaps create-diff-object could save the user the investigation? Would something like the following (a rough draft) be worth adding to the static local correlation logic:
@@ -1408,10 +1408,14 @@ static void kpatch_correlate_static_local_variables(struct kpatch_elf *orig,
}
patched_sym = kpatch_find_static_twin(relasec, sym);
- if (!patched_sym)+ if (!patched_sym) {+ if (!find_section_by_name(&patched->sections, relasec->name))+ log_normal("section %s was removed, %s may have been inlined?\n",+ relasec->name, kpatch_section_function_name(relasec));
DIFF_FATAL("reference to static local variable %s in %s was removed",
sym->name,
kpatch_section_function_name(relasec));
+ }
patched_bundled = patched_sym == patched_sym->sec->sym;
if (bundled != patched_bundled)
which would emit additional guidance:
cls_flower.ORIG.o: section .rela.text.fl_set_geneve_opt was removed, fl_set_geneve_opt may have been inlined?
ERROR: cls_flower.ORIG.o: reference to static local variable __msg.59123 in fl_set_geneve_opt was removed
create-diff-object: unreconcilable difference
Alternatively we could document what to do in the patch author guide in case of this error message. It may be easy to work around an inline case like this one, but others may require a real workaround in the code.
Yes, printing the name of the possibly inlined function in such cases does help a lot, saves a significant amount of time when investigating build failures.
Would a similar correlation problem would exist in the opposite case: function A was inlined with a static local that belonged to parent callers B and C, but then the patched version promotes A to a real function and now there is a new static local for A and the ones formerly associated with B and C are removed.
@ryanbsull noticed this when building a CVE-2023-35788 kpatch for some releases of RHEL on ppc64le:
Which is interesting given the patch only adds a small conditional to fl_set_geneve_opt().
When comparing the original cls_flower.o to the patched cls_flower.o, it seems that the compiler has converted fl_set_geneve_opt() from a function to an inlined one (thanks -O3 optimization). In order to debug this, we looked at the symbol tables for each object file and compared them -- an equal number of __msg. variables, but no fl_set_geneve_opt symbol in the patched object.
Modifying the kpatch to mark fl_set_geneve_opt as
noinline
avoided the build error, but perhaps create-diff-object could save the user the investigation? Would something like the following (a rough draft) be worth adding to the static local correlation logic:which would emit additional guidance:
Alternatively we could document what to do in the patch author guide in case of this error message. It may be easy to work around an inline case like this one, but others may require a real workaround in the code.
repro-inlined-static-local.tar.gz
The text was updated successfully, but these errors were encountered: