From: kernel test robot <lkp@intel.com>
To: Yonghong Song <yhs@fb.com>, bpf@vger.kernel.org
Cc: kbuild-all@lists.01.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com
Subject: Re: [PATCH bpf-next 04/12] libbpf: Add btf enum64 support
Date: Wed, 4 May 2022 01:22:50 +0800 [thread overview]
Message-ID: <202205040133.jd7yTwg5-lkp@intel.com> (raw)
In-Reply-To: <20220501190023.2578209-1-yhs@fb.com>
Hi Yonghong,
I love your patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/Yonghong-Song/bpf-Add-64bit-enum-value-support/20220502-030301
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386-randconfig-m021 (https://download.01.org/0day-ci/archive/20220504/202205040133.jd7yTwg5-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.2.0-20) 11.2.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
New smatch warnings:
tools/lib/bpf/relo_core.c:348 bpf_core_fields_are_compat() warn: if();
Old smatch warnings:
tools/lib/bpf/relo_core.c:349 bpf_core_fields_are_compat() warn: if();
vim +348 tools/lib/bpf/relo_core.c
314
315 /* Check two types for compatibility for the purpose of field access
316 * relocation. const/volatile/restrict and typedefs are skipped to ensure we
317 * are relocating semantically compatible entities:
318 * - any two STRUCTs/UNIONs are compatible and can be mixed;
319 * - any two FWDs are compatible, if their names match (modulo flavor suffix);
320 * - any two PTRs are always compatible;
321 * - for ENUMs, names should be the same (ignoring flavor suffix) or at
322 * least one of enums should be anonymous;
323 * - for ENUMs, check sizes, names are ignored;
324 * - for INT, size and signedness are ignored;
325 * - any two FLOATs are always compatible;
326 * - for ARRAY, dimensionality is ignored, element types are checked for
327 * compatibility recursively;
328 * - everything else shouldn't be ever a target of relocation.
329 * These rules are not set in stone and probably will be adjusted as we get
330 * more experience with using BPF CO-RE relocations.
331 */
332 static int bpf_core_fields_are_compat(const struct btf *local_btf,
333 __u32 local_id,
334 const struct btf *targ_btf,
335 __u32 targ_id)
336 {
337 const struct btf_type *local_type, *targ_type;
338
339 recur:
340 local_type = skip_mods_and_typedefs(local_btf, local_id, &local_id);
341 targ_type = skip_mods_and_typedefs(targ_btf, targ_id, &targ_id);
342 if (!local_type || !targ_type)
343 return -EINVAL;
344
345 if (btf_is_composite(local_type) && btf_is_composite(targ_type))
346 return 1;
347 if (btf_kind(local_type) != btf_kind(targ_type)) {
> 348 if (btf_is_enum(local_type) && btf_is_enum64(targ_type)) ;
349 else if (btf_is_enum64(local_type) && btf_is_enum(targ_type)) ;
350 else return 0;
351 }
352
353 switch (btf_kind(local_type)) {
354 case BTF_KIND_PTR:
355 case BTF_KIND_FLOAT:
356 return 1;
357 case BTF_KIND_FWD:
358 case BTF_KIND_ENUM:
359 case BTF_KIND_ENUM64: {
360 const char *local_name, *targ_name;
361 size_t local_len, targ_len;
362
363 local_name = btf__name_by_offset(local_btf,
364 local_type->name_off);
365 targ_name = btf__name_by_offset(targ_btf, targ_type->name_off);
366 local_len = bpf_core_essential_name_len(local_name);
367 targ_len = bpf_core_essential_name_len(targ_name);
368 /* one of them is anonymous or both w/ same flavor-less names */
369 return local_len == 0 || targ_len == 0 ||
370 (local_len == targ_len &&
371 strncmp(local_name, targ_name, local_len) == 0);
372 }
373 case BTF_KIND_INT:
374 /* just reject deprecated bitfield-like integers; all other
375 * integers are by default compatible between each other
376 */
377 return btf_int_offset(local_type) == 0 &&
378 btf_int_offset(targ_type) == 0;
379 case BTF_KIND_ARRAY:
380 local_id = btf_array(local_type)->type;
381 targ_id = btf_array(targ_type)->type;
382 goto recur;
383 default:
384 return 0;
385 }
386 }
387
--
0-DAY CI Kernel Test Service
https://01.org/lkp
next prev parent reply other threads:[~2022-05-03 17:23 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-01 19:00 [PATCH bpf-next 00/12] bpf: Add 64bit enum value support Yonghong Song
2022-05-01 19:00 ` [PATCH bpf-next 01/12] bpf: Add btf enum64 support Yonghong Song
2022-05-09 0:33 ` Dave Marchevsky
2022-05-09 22:29 ` Andrii Nakryiko
2022-05-10 22:06 ` Yonghong Song
2022-05-10 23:18 ` Andrii Nakryiko
2022-05-11 0:17 ` Yonghong Song
2022-05-01 19:00 ` [PATCH bpf-next 02/12] libbpf: Permit 64bit relocation value Yonghong Song
2022-05-09 1:06 ` Dave Marchevsky
2022-05-10 19:35 ` Yonghong Song
2022-05-09 22:37 ` Andrii Nakryiko
2022-05-10 22:14 ` Yonghong Song
2022-05-10 23:19 ` Andrii Nakryiko
2022-05-01 19:00 ` [PATCH bpf-next 03/12] libbpf: Fix an error in 64bit relocation value computation Yonghong Song
2022-05-09 0:55 ` Dave Marchevsky
2022-05-09 0:56 ` Dave Marchevsky
2022-05-09 22:37 ` Andrii Nakryiko
2022-05-10 22:11 ` Yonghong Song
2022-05-01 19:00 ` [PATCH bpf-next 04/12] libbpf: Add btf enum64 support Yonghong Song
2022-05-03 17:22 ` kernel test robot [this message]
2022-05-05 22:44 ` Yonghong Song
2022-05-09 23:25 ` Andrii Nakryiko
2022-05-10 22:40 ` Yonghong Song
2022-05-10 23:02 ` Yonghong Song
2022-05-10 23:40 ` Andrii Nakryiko
2022-05-10 23:38 ` Andrii Nakryiko
2022-05-11 0:39 ` Yonghong Song
2022-05-11 17:43 ` Andrii Nakryiko
2022-05-11 18:56 ` Yonghong Song
2022-05-01 19:00 ` [PATCH bpf-next 05/12] bpftool: " Yonghong Song
2022-05-09 23:31 ` Andrii Nakryiko
2022-05-10 22:43 ` Yonghong Song
2022-05-01 19:00 ` [PATCH bpf-next 06/12] selftests/bpf: Fix selftests failure Yonghong Song
2022-05-09 2:21 ` Dave Marchevsky
2022-05-10 19:40 ` Yonghong Song
2022-05-09 23:34 ` Andrii Nakryiko
2022-05-10 22:44 ` Yonghong Song
2022-05-01 19:00 ` [PATCH bpf-next 07/12] selftests/bpf: Test new libbpf enum32/enum64 API functions Yonghong Song
2022-05-01 19:00 ` [PATCH bpf-next 08/12] selftests/bpf: Add BTF_KIND_ENUM64 unit tests Yonghong Song
2022-05-01 19:00 ` [PATCH bpf-next 09/12] selftests/bpf: Test BTF_KIND_ENUM64 for deduplication Yonghong Song
2022-05-09 23:37 ` Andrii Nakryiko
2022-05-10 22:44 ` Yonghong Song
2022-05-01 19:00 ` [PATCH bpf-next 10/12] selftests/bpf: add a test for enum64 value relocation Yonghong Song
2022-05-09 23:38 ` Andrii Nakryiko
2022-05-10 22:45 ` Yonghong Song
2022-05-01 19:00 ` [PATCH bpf-next 11/12] selftests/bpf: Clarify llvm dependency with possible selftest failures Yonghong Song
2022-05-01 19:01 ` [PATCH bpf-next 12/12] docs/bpf: Update documentation for BTF_KIND_ENUM64 support Yonghong Song
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=202205040133.jd7yTwg5-lkp@intel.com \
--to=lkp@intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kbuild-all@lists.01.org \
--cc=kernel-team@fb.com \
--cc=yhs@fb.com \
/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