On Tue, Nov 16, 2021 at 04:58:23PM -0800, Andrii Nakryiko wrote:
> >
> > -#define BPF_CORE_SPEC_MAX_LEN 64
> > +#define BPF_CORE_SPEC_MAX_LEN 32
>
> This is worth calling out in the commit description, should have
> practical implications, but good to mention.
good point.
>
> >
> > /* represents BPF CO-RE field or array element accessor */
> > struct bpf_core_accessor {
> > @@ -272,8 +325,8 @@ static int bpf_core_parse_spec(const struct btf *btf,
> > return sz;
> > spec->bit_offset += access_idx * sz * 8;
> > } else {
> > - pr_warn("relo for [%u] %s (at idx %d) captures type [%d] of unexpected kind %s\n",
> > - type_id, spec_str, i, id, btf_kind_str(t));
> > +/* pr_warn("relo for [%u] %s (at idx %d) captures type [%d] of unexpected kind %s\n",
> > + type_id, spec_str, i, id, btf_kind_str(t));*/
>
> we can totally pass prog_name and add "prog '%s': " to uncomment this.
> bpf_core_parse_spec() is called in the "context" of program, so it's
> known
Sure.
> > return -EINVAL;
> > }
> > }
> > @@ -346,8 +399,8 @@ static int bpf_core_fields_are_compat(const struct btf *local_btf,
> > targ_id = btf_array(targ_type)->type;
> > goto recur;
> > default:
> > - pr_warn("unexpected kind %d relocated, local [%d], target [%d]\n",
> > - btf_kind(local_type), local_id, targ_id);
> > +/* pr_warn("unexpected kind %d relocated, local [%d], target [%d]\n",
> > + btf_kind(local_type), local_id, targ_id);*/
>
> sigh... it's a bit too intrusive to pass prog_name here but it's also
> highly unlikely that this happens (unless some compiler bug or
> corruption) and even in that case it's semantically correct that
> fields just don't match. So I'd just drop this pr_warn() instead of
> commenting it out
makes sense to me. will do.
