BPF List
 help / color / mirror / Atom feed
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

  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