Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] Build failure due to undeclared mapping symbol functions. - [Low] Unused header inclusion. --
commit 4ad78a24a64cd6a2d10b9a2f9c0d306fba3e6d19 Author: Josh Poimboeuf <[email protected]> objtool: Prevent kCFI hashes from being decoded as instructions On arm64 with CONFIG_CFI=y, Clang places a 4-byte kCFI type hash immediately before each address-taken function entry. This commit uses mapping symbols to mark such data as NOP in text sections to prevent objtool from decoding them. > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index e05dc7a93dc1e..2b03a2d6fc952 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -25,6 +25,7 @@ > #include <linux/kernel.h> > #include <linux/static_call_types.h> > #include <linux/string.h> > +#include <linux/kconfig.h> This isn't a bug, but is this include needed? It doesn't appear that any Kconfig configuration macros are being used in the modified code. [ ... ] > @@ -478,6 +483,16 @@ static int decode_instructions(struct objtool_file *file) > > prev_len = insn->len; > > + /* Use mapping symbols to skip data in text sections */ > + sec_for_each_sym_from(sec, map_sym) { > + if (map_sym->offset > offset) > + break; > + if (is_mapping_sym(map_sym)) > + is_data = is_data_mapping_sym(map_sym); Could this cause a build failure across architectures here? It appears is_mapping_sym() and is_data_mapping_sym() are neither declared nor defined anywhere in the codebase at this point in the patch series. If these functions are only introduced in a subsequent commit, applying this patch independently might result in an implicit declaration of function error, breaking git bisectability. > + } > + if (is_data) > + insn->type = INSN_NOP; > + > /* -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=14
