[kbuild-all] [ast-bpf:relo_core 9/19] tools/lib/bpf/relo_core.c:1198:5: warning: stack frame size (1288) exceeds limit (1024) in 'bpf_core_apply_relo_insn'

Hi Alexei, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git relo_core head: f17ef55e5e0bac0d11d3186cd1c468b5a1e047d7 commit: 03c354f8c71c2478c421d5552d284e0befb03861 [9/19] bpf: Prepare relo_core.c for kernel duty. config: hexagon-randconfig-r045-20211115 (attached as .config) compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project c3dddeeafb529e769cde87bd29ef6271ac6bfa5c) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?id=03... git remote add ast-bpf https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git git fetch --no-tags ast-bpf relo_core git checkout 03c354f8c71c2478c421d5552d284e0befb03861 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=hexagon If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com&gt; All warnings (new ones prefixed by >>): int bpf_core_apply_relo_insn(const char *prog_name, struct bpf_insn *insn, ^ 1 warning generated. vim +/bpf_core_apply_relo_insn +1198 tools/lib/bpf/relo_core.c b0588390dbcedc Alexei Starovoitov 2021-07-20 1147 b0588390dbcedc Alexei Starovoitov 2021-07-20 1148 /* b0588390dbcedc Alexei Starovoitov 2021-07-20 1149 * CO-RE relocate single instruction. b0588390dbcedc Alexei Starovoitov 2021-07-20 1150 * b0588390dbcedc Alexei Starovoitov 2021-07-20 1151 * The outline and important points of the algorithm: b0588390dbcedc Alexei Starovoitov 2021-07-20 1152 * 1. For given local type, find corresponding candidate target types. b0588390dbcedc Alexei Starovoitov 2021-07-20 1153 * Candidate type is a type with the same "essential" name, ignoring b0588390dbcedc Alexei Starovoitov 2021-07-20 1154 * everything after last triple underscore (___). E.g., `sample`, b0588390dbcedc Alexei Starovoitov 2021-07-20 1155 * `sample___flavor_one`, `sample___flavor_another_one`, are all candidates b0588390dbcedc Alexei Starovoitov 2021-07-20 1156 * for each other. Names with triple underscore are referred to as b0588390dbcedc Alexei Starovoitov 2021-07-20 1157 * "flavors" and are useful, among other things, to allow to b0588390dbcedc Alexei Starovoitov 2021-07-20 1158 * specify/support incompatible variations of the same kernel struct, which b0588390dbcedc Alexei Starovoitov 2021-07-20 1159 * might differ between different kernel versions and/or build b0588390dbcedc Alexei Starovoitov 2021-07-20 1160 * configurations. b0588390dbcedc Alexei Starovoitov 2021-07-20 1161 * b0588390dbcedc Alexei Starovoitov 2021-07-20 1162 * N.B. Struct "flavors" could be generated by bpftool's BTF-to-C b0588390dbcedc Alexei Starovoitov 2021-07-20 1163 * converter, when deduplicated BTF of a kernel still contains more than b0588390dbcedc Alexei Starovoitov 2021-07-20 1164 * one different types with the same name. In that case, ___2, ___3, etc b0588390dbcedc Alexei Starovoitov 2021-07-20 1165 * are appended starting from second name conflict. But start flavors are b0588390dbcedc Alexei Starovoitov 2021-07-20 1166 * also useful to be defined "locally", in BPF program, to extract same b0588390dbcedc Alexei Starovoitov 2021-07-20 1167 * data from incompatible changes between different kernel b0588390dbcedc Alexei Starovoitov 2021-07-20 1168 * versions/configurations. For instance, to handle field renames between b0588390dbcedc Alexei Starovoitov 2021-07-20 1169 * kernel versions, one can use two flavors of the struct name with the b0588390dbcedc Alexei Starovoitov 2021-07-20 1170 * same common name and use conditional relocations to extract that field, b0588390dbcedc Alexei Starovoitov 2021-07-20 1171 * depending on target kernel version. b0588390dbcedc Alexei Starovoitov 2021-07-20 1172 * 2. For each candidate type, try to match local specification to this b0588390dbcedc Alexei Starovoitov 2021-07-20 1173 * candidate target type. Matching involves finding corresponding b0588390dbcedc Alexei Starovoitov 2021-07-20 1174 * high-level spec accessors, meaning that all named fields should match, b0588390dbcedc Alexei Starovoitov 2021-07-20 1175 * as well as all array accesses should be within the actual bounds. Also, b0588390dbcedc Alexei Starovoitov 2021-07-20 1176 * types should be compatible (see bpf_core_fields_are_compat for details). b0588390dbcedc Alexei Starovoitov 2021-07-20 1177 * 3. It is supported and expected that there might be multiple flavors b0588390dbcedc Alexei Starovoitov 2021-07-20 1178 * matching the spec. As long as all the specs resolve to the same set of b0588390dbcedc Alexei Starovoitov 2021-07-20 1179 * offsets across all candidates, there is no error. If there is any b0588390dbcedc Alexei Starovoitov 2021-07-20 1180 * ambiguity, CO-RE relocation will fail. This is necessary to accomodate b0588390dbcedc Alexei Starovoitov 2021-07-20 1181 * imprefection of BTF deduplication, which can cause slight duplication of b0588390dbcedc Alexei Starovoitov 2021-07-20 1182 * the same BTF type, if some directly or indirectly referenced (by b0588390dbcedc Alexei Starovoitov 2021-07-20 1183 * pointer) type gets resolved to different actual types in different b0588390dbcedc Alexei Starovoitov 2021-07-20 1184 * object files. If such situation occurs, deduplicated BTF will end up b0588390dbcedc Alexei Starovoitov 2021-07-20 1185 * with two (or more) structurally identical types, which differ only in b0588390dbcedc Alexei Starovoitov 2021-07-20 1186 * types they refer to through pointer. This should be OK in most cases and b0588390dbcedc Alexei Starovoitov 2021-07-20 1187 * is not an error. b0588390dbcedc Alexei Starovoitov 2021-07-20 1188 * 4. Candidate types search is performed by linearly scanning through all b0588390dbcedc Alexei Starovoitov 2021-07-20 1189 * types in target BTF. It is anticipated that this is overall more b0588390dbcedc Alexei Starovoitov 2021-07-20 1190 * efficient memory-wise and not significantly worse (if not better) b0588390dbcedc Alexei Starovoitov 2021-07-20 1191 * CPU-wise compared to prebuilding a map from all local type names to b0588390dbcedc Alexei Starovoitov 2021-07-20 1192 * a list of candidate type names. It's also sped up by caching resolved b0588390dbcedc Alexei Starovoitov 2021-07-20 1193 * list of matching candidates per each local "root" type ID, that has at b0588390dbcedc Alexei Starovoitov 2021-07-20 1194 * least one bpf_core_relo associated with it. This list is shared b0588390dbcedc Alexei Starovoitov 2021-07-20 1195 * between multiple relocations for the same type ID and is updated as some b0588390dbcedc Alexei Starovoitov 2021-07-20 1196 * of the candidates are pruned due to structural incompatibility. b0588390dbcedc Alexei Starovoitov 2021-07-20 1197 */ b0588390dbcedc Alexei Starovoitov 2021-07-20 @1198 int bpf_core_apply_relo_insn(const char *prog_name, struct bpf_insn *insn, :::::: The code at line 1198 was first introduced by commit :::::: b0588390dbcedcd74fab6ffb8afe8d52380fd8b6 libbpf: Split CO-RE logic into relo_core.c. :::::: TO: Alexei Starovoitov <ast(a)kernel.org&gt; :::::: CC: Andrii Nakryiko <andrii(a)kernel.org&gt; --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org