From: kernel test robot <lkp@intel.com>
To: Alexei Starovoitov <ast@kernel.org>
Cc: llvm@lists.linux.dev, kbuild-all@lists.01.org,
linux-kernel@vger.kernel.org
Subject: [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'
Date: Mon, 15 Nov 2021 06:00:13 +0800 [thread overview]
Message-ID: <202111150609.9hiur3MO-lkp@intel.com> (raw)
[-- 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 --]
reply other threads:[~2021-11-14 22:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202111150609.9hiur3MO-lkp@intel.com \
--to=lkp@intel.com \
--cc=ast@kernel.org \
--cc=kbuild-all@lists.01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).