All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel Müller" <deso@posteo.net>
To: Quentin Monnet <quentin@isovalent.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
	daniel@iogearbox.net, kernel-team@fb.com, joannelkoong@gmail.com,
	"Mauricio Vásquez" <mauricio@kinvolk.io>
Subject: Re: [PATCH bpf-next v2 2/9] bpftool: Honor BPF_CORE_TYPE_MATCHES relocation
Date: Mon, 27 Jun 2022 16:43:17 +0000	[thread overview]
Message-ID: <20220627164317.k7rkbrtlkzsa4ypk@muellerd-fedora-MJ0AC3F3> (raw)
In-Reply-To: <a4770a25-b78a-d721-4d30-ae58feec965c@isovalent.com>

On Fri, Jun 24, 2022 at 12:37:09PM +0100, Quentin Monnet wrote:
> 2022-06-23 21:21 UTC+0000 ~ Daniel Müller <deso@posteo.net>
> > bpftool needs to know about the newly introduced BPF_CORE_TYPE_MATCHES
> > relocation for its 'gen min_core_btf' command to work properly in the
> > present of this relocation.
> > Specifically, we need to make sure to mark types and fields so that they
> > are present in the minimized BTF for "type match" checks to work out.
> > However, contrary to the existing btfgen_record_field_relo, we need to
> > rely on the BTF -- and not the spec -- to find fields. With this change
> > we handle this new variant correctly. The functionality will be tested
> > with follow on changes to BPF selftests, which already run against a
> > minimized BTF created with bpftool.
> > 
> > Cc: Quentin Monnet <quentin@isovalent.com>
> > Signed-off-by: Daniel Müller <deso@posteo.net>
> > ---
> >  tools/bpf/bpftool/gen.c | 107 ++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 107 insertions(+)
> > 
> > diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> > index 480cbd8..6cd0ed 100644
> > --- a/tools/bpf/bpftool/gen.c
> > +++ b/tools/bpf/bpftool/gen.c
> > @@ -1856,6 +1856,111 @@ static int btfgen_record_field_relo(struct btfgen_info *info, struct bpf_core_sp
> >  	return 0;
> >  }
> >  
> > +/* Mark types, members, and member types. Compared to btfgen_record_field_relo,
> > + * this function does not rely on the target spec for inferring members, but
> > + * uses the associated BTF.
> > + *
> > + * The `behind_ptr` argument is used to stop marking of composite types reached
> > + * through a pointer. This way, we keep can keep BTF size in check while
> 
> Typo, "we keep can keep"

Fixed. Thanks!

> > + * providing reasonable match semantics.
> > + */
> > +static int btfgen_mark_types_match(struct btfgen_info *info, __u32 type_id, bool behind_ptr)
> > +{
> > +	const struct btf_type *btf_type;
> > +	struct btf *btf = info->src_btf;
> > +	struct btf_type *cloned_type;
> > +	int i, err;
> > +
> > +	if (type_id == 0)
> > +		return 0;
> > +
> > +	btf_type = btf__type_by_id(btf, type_id);
> > +	/* mark type on cloned BTF as used */
> > +	cloned_type = (struct btf_type *)btf__type_by_id(info->marked_btf, type_id);
> > +	cloned_type->name_off = MARKED;
> > +
> > +	switch (btf_kind(btf_type)) {
> > +	case BTF_KIND_UNKN:
> > +	case BTF_KIND_INT:
> > +	case BTF_KIND_FLOAT:
> > +	case BTF_KIND_ENUM:
> > +	case BTF_KIND_ENUM64:
> > +		break;
> > +	case BTF_KIND_STRUCT:
> > +	case BTF_KIND_UNION: {
> > +		struct btf_member *m = btf_members(btf_type);
> > +		__u16 vlen = btf_vlen(btf_type);
> > +
> > +		if (behind_ptr)
> > +			break;
> > +
> > +		for (i = 0; i < vlen; i++, m++) {
> > +			/* mark member */
> > +			btfgen_mark_member(info, type_id, i);
> > +
> > +			/* mark member's type */
> > +			err = btfgen_mark_types_match(info, m->type, false);
> > +			if (err)
> > +				return err;
> > +		}
> > +		break;
> > +	}
> > +	case BTF_KIND_CONST:
> > +	case BTF_KIND_FWD:
> > +	case BTF_KIND_VOLATILE:
> > +	case BTF_KIND_TYPEDEF:
> > +		return btfgen_mark_types_match(info, btf_type->type, false);
> > +	case BTF_KIND_PTR:
> > +		return btfgen_mark_types_match(info, btf_type->type, true);
> > +	case BTF_KIND_ARRAY: {
> > +		struct btf_array *array;
> > +
> > +		array = btf_array(btf_type);
> > +		/* mark array type */
> > +		err = btfgen_mark_types_match(info, array->type, false);
> > +		/* mark array's index type */
> > +		err = err ? : btfgen_mark_types_match(info, array->index_type, false);
> > +		if (err)
> > +			return err;
> > +		break;
> > +	}
> > +	case BTF_KIND_FUNC_PROTO: {
> > +		__u16 vlen = btf_vlen(btf_type);
> > +		struct btf_param *param;
> > +
> > +		/* mark ret type */
> > +		err = btfgen_mark_types_match(info, btf_type->type, false);
> > +		if (err)
> > +			return err;
> > +
> > +		/* mark parameters types */
> > +		param = btf_params(btf_type);
> > +		for (i = 0; i < vlen; i++) {
> > +			err = btfgen_mark_types_match(info, param->type, false);
> > +			if (err)
> > +				return err;
> > +			param++;
> > +		}
> > +		break;
> > +	}
> > +	/* tells if some other type needs to be handled */
> > +	default:
> > +		p_err("unsupported kind: %s (%d)", btf_kind_str(btf_type), type_id);
> > +		return -EINVAL;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +/* Mark types, members, and member types. Compared to btfgen_record_field_relo,
> > + * this function does not rely on the target spec for inferring members, but
> > + * uses the associated BTF.
> > + */
> > +static int btfgen_record_types_match_relo(struct btfgen_info *info, struct bpf_core_spec *targ_spec)
> 
> Nit: Maybe btfgen_record_type_match_relo() ("type" singular), for
> consistency with btfgen_record_type_relo()?

Sure, changed.

> > +{
> > +	return btfgen_mark_types_match(info, targ_spec->root_type_id, false);
> > +}
> > +
> >  static int btfgen_record_type_relo(struct btfgen_info *info, struct bpf_core_spec *targ_spec)
> >  {
> >  	return btfgen_mark_type(info, targ_spec->root_type_id, true);
> > @@ -1882,6 +1987,8 @@ static int btfgen_record_reloc(struct btfgen_info *info, struct bpf_core_spec *r
> >  	case BPF_CORE_TYPE_EXISTS:
> >  	case BPF_CORE_TYPE_SIZE:
> >  		return btfgen_record_type_relo(info, res);
> > +	case BPF_CORE_TYPE_MATCHES:
> > +		return btfgen_record_types_match_relo(info, res);
> >  	case BPF_CORE_ENUMVAL_EXISTS:
> >  	case BPF_CORE_ENUMVAL_VALUE:
> >  		return btfgen_record_enumval_relo(info, res);
> 
> Aside from the minor nits, the patch looks good to me. Thanks!

Thanks for your review!

Daniel

> Acked-by: Quentin Monnet <quentin@isovalent.com>

  reply	other threads:[~2022-06-27 16:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23 21:21 [PATCH bpf-next v2 0/9] Introduce type match support Daniel Müller
2022-06-23 21:21 ` [PATCH bpf-next v2 1/9] bpf: Introduce TYPE_MATCH related constants/macros Daniel Müller
2022-06-23 21:21 ` [PATCH bpf-next v2 2/9] bpftool: Honor BPF_CORE_TYPE_MATCHES relocation Daniel Müller
2022-06-24 11:37   ` Quentin Monnet
2022-06-27 16:43     ` Daniel Müller [this message]
2022-06-24 21:25   ` Andrii Nakryiko
2022-06-27 16:50     ` Daniel Müller
2022-06-23 21:21 ` [PATCH bpf-next v2 3/9] bpf: Introduce btf_int_bits() function Daniel Müller
2022-06-23 21:22 ` [PATCH bpf-next v2 4/9] libbpf: Add type match support Daniel Müller
2022-06-24 21:39   ` Andrii Nakryiko
2022-06-27 21:28     ` Daniel Müller
2022-06-23 21:22 ` [PATCH bpf-next v2 5/9] bpf: " Daniel Müller
2022-06-23 21:22 ` [PATCH bpf-next v2 6/9] libbpf: Honor TYPE_MATCH relocation Daniel Müller
2022-06-24 21:41   ` Andrii Nakryiko
2022-06-23 21:22 ` [PATCH bpf-next v2 7/9] selftests/bpf: Add type-match checks to type-based tests Daniel Müller
2022-06-23 21:22 ` [PATCH bpf-next v2 8/9] selftests/bpf: Add test checking more characteristics Daniel Müller
2022-06-23 21:22 ` [PATCH bpf-next v2 9/9] selftests/bpf: Add nested type to type based tests Daniel Müller
2022-06-24 21:45   ` Andrii Nakryiko
2022-06-27 23:06     ` Daniel Müller

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=20220627164317.k7rkbrtlkzsa4ypk@muellerd-fedora-MJ0AC3F3 \
    --to=deso@posteo.net \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=joannelkoong@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=mauricio@kinvolk.io \
    --cc=quentin@isovalent.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 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.