From: Yonghong Song <yhs@fb.com> To: kernel test robot <lkp@intel.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: Thu, 5 May 2022 15:44:54 -0700 [thread overview] Message-ID: <7c65e346-6e51-4f06-99de-adaa129cf9f8@fb.com> (raw) In-Reply-To: <202205040133.jd7yTwg5-lkp@intel.com> On 5/3/22 10:22 AM, kernel test robot wrote: > 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(); The following change should work: diff --git a/tools/lib/bpf/relo_core.c b/tools/lib/bpf/relo_core.c index 1e751400427b..2c8d5292e946 100644 --- a/tools/lib/bpf/relo_core.c +++ b/tools/lib/bpf/relo_core.c @@ -345,9 +345,8 @@ static int bpf_core_fields_are_compat(const struct btf *local_btf, if (btf_is_composite(local_type) && btf_is_composite(targ_type)) return 1; if (btf_kind(local_type) != btf_kind(targ_type)) { - if (btf_is_enum(local_type) && btf_is_enum64(targ_type)) ; - else if (btf_is_enum64(local_type) && btf_is_enum(targ_type)) ; - else return 0; + if (!btf_is_enum(local_type) || !btf_is_enum64(targ_type)) + return 0; } switch (btf_kind(local_type)) { I will wait for more comments before submitting version 2. > > 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 >
WARNING: multiple messages have this Message-ID (diff)
From: Yonghong Song <yhs@fb.com> To: kbuild-all@lists.01.org Subject: Re: [PATCH bpf-next 04/12] libbpf: Add btf enum64 support Date: Thu, 05 May 2022 15:44:54 -0700 [thread overview] Message-ID: <7c65e346-6e51-4f06-99de-adaa129cf9f8@fb.com> (raw) In-Reply-To: <202205040133.jd7yTwg5-lkp@intel.com> [-- Attachment #1: Type: text/plain, Size: 5320 bytes --] On 5/3/22 10:22 AM, kernel test robot wrote: > 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(a)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(); The following change should work: diff --git a/tools/lib/bpf/relo_core.c b/tools/lib/bpf/relo_core.c index 1e751400427b..2c8d5292e946 100644 --- a/tools/lib/bpf/relo_core.c +++ b/tools/lib/bpf/relo_core.c @@ -345,9 +345,8 @@ static int bpf_core_fields_are_compat(const struct btf *local_btf, if (btf_is_composite(local_type) && btf_is_composite(targ_type)) return 1; if (btf_kind(local_type) != btf_kind(targ_type)) { - if (btf_is_enum(local_type) && btf_is_enum64(targ_type)) ; - else if (btf_is_enum64(local_type) && btf_is_enum(targ_type)) ; - else return 0; + if (!btf_is_enum(local_type) || !btf_is_enum64(targ_type)) + return 0; } switch (btf_kind(local_type)) { I will wait for more comments before submitting version 2. > > 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 >
next prev parent reply other threads:[~2022-05-05 22:45 UTC|newest] Thread overview: 48+ 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 2022-05-05 22:44 ` Yonghong Song [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=7c65e346-6e51-4f06-99de-adaa129cf9f8@fb.com \ --to=yhs@fb.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=lkp@intel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.