linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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'
@ 2021-11-14 22:00 kernel test robot
  0 siblings, 0 replies; only message in thread
From: kernel test robot @ 2021-11-14 22:00 UTC (permalink / raw)
  To: Alexei Starovoitov; +Cc: llvm, kbuild-all, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 7918 bytes --]

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=03c354f8c71c2478c421d5552d284e0befb03861
        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@intel.com>

All warnings (new ones prefixed by >>):

>> tools/lib/bpf/relo_core.c:1198:5: warning: stack frame size (1288) exceeds limit (1024) in 'bpf_core_apply_relo_insn' [-Wframe-larger-than]
   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@kernel.org>
:::::: CC: Andrii Nakryiko <andrii@kernel.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28005 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-11-14 22:01 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-14 22:00 [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' kernel test robot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).