All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: bpf@vger.kernel.org, "Alexei Starovoitov" <ast@kernel.org>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>
Subject: Re: [PATCH bpf-next v2 02/15] bpf: Make btf_find_field more generic
Date: Sat, 19 Mar 2022 14:30:54 -0700	[thread overview]
Message-ID: <20220319213054.e27i6saz73s7snsi@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20220319200641.om64ihmaaqkq2nof@apollo>

On Sun, Mar 20, 2022 at 01:36:41AM +0530, Kumar Kartikeya Dwivedi wrote:
> > > >  			return -EINVAL;
> > > > +
> > > > +		switch (field_type) {
> > > > +		case BTF_FIELD_SPIN_LOCK:
> > > > +		case BTF_FIELD_TIMER:
> > >
> > > Since spin_lock vs timer is passed into btf_find_struct_field() as field_type
> > > argument there is no need to pass name, sz, align from the caller.
> > > Pls make btf_find_spin_lock() to pass BTF_FIELD_SPIN_LOCK only
> > > and in the above code do something like:
> > >  switch (field_type) {
> > >  case BTF_FIELD_SPIN_LOCK:
> > >      name = "bpf_spin_lock";
> > >      sz = ...
> > >      break;
> > >  case BTF_FIELD_TIMER:
> > >      name = "bpf_timer";
> > >      sz = ...
> > >      break;
> > >  }
> >
> > Would doing this in btf_find_field be better? Then we set these once instead of
> > doing it twice in btf_find_struct_field, and btf_find_datasec_var.

yeah. probably.

> >
> > >  switch (field_type) {
> > >  case BTF_FIELD_SPIN_LOCK:
> > >  case BTF_FIELD_TIMER:
> > > 	if (!__btf_type_is_struct(member_type))
> > > 		continue;
> > > 	if (strcmp(__btf_name_by_offset(btf, member_type->name_off), name))
> > >         ...
> > >         btf_find_field_struct(btf, member_type, off, sz, info);
> > >  }
> > >
> > > It will cleanup the later patch which passes NULL, sizeof(u64), alignof(u64)
> > > only to pass something into the function.
> > > With above suggestion it wouldn't need to pass dummy args. BTF_FIELD_KPTR will be enough.
> > >
> 
> Just to be clear, for the kptr case we still use size and align, only name is
> optional. size is used for datasec_var call, align is used in both struct_field
> and datasec_var. So I'm not sure whether moving it around has much effect,
> instead of the caller it will now be set based on field_type inside
> btf_find_field.

There is no use case to do BTF_FIELD_KPTR, sizeof(u64) and BTF_FIELD_KPTR, sizeof(u32), right?
So best to avoid such mistakes.
In other words consider every function to be a uapi.
Not in a way that it can never change, but from pov that you wouldn't want the user space
to specify all details for the kernel when BTF_FIELD_KPTR is enough to figure out the rest.

  reply	other threads:[~2022-03-19 21:31 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-17 11:59 [PATCH bpf-next v2 00/15] Introduce typed pointer support in BPF maps Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 01/15] bpf: Factor out fd returning from bpf_btf_find_by_name_kind Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 02/15] bpf: Make btf_find_field more generic Kumar Kartikeya Dwivedi
2022-03-19 17:55   ` Alexei Starovoitov
2022-03-19 19:31     ` Kumar Kartikeya Dwivedi
2022-03-19 20:06       ` Kumar Kartikeya Dwivedi
2022-03-19 21:30         ` Alexei Starovoitov [this message]
2022-03-17 11:59 ` [PATCH bpf-next v2 03/15] bpf: Allow storing unreferenced kptr in map Kumar Kartikeya Dwivedi
2022-03-19 18:15   ` Alexei Starovoitov
2022-03-19 18:52     ` Kumar Kartikeya Dwivedi
2022-03-19 21:17       ` Alexei Starovoitov
2022-03-19 21:39         ` Kumar Kartikeya Dwivedi
2022-03-19 21:50           ` Kumar Kartikeya Dwivedi
2022-03-19 22:57             ` Alexei Starovoitov
2022-03-17 11:59 ` [PATCH bpf-next v2 04/15] bpf: Allow storing referenced " Kumar Kartikeya Dwivedi
2022-03-19 18:24   ` Alexei Starovoitov
2022-03-19 18:59     ` Kumar Kartikeya Dwivedi
2022-03-19 21:23       ` Alexei Starovoitov
2022-03-19 21:43         ` Kumar Kartikeya Dwivedi
2022-03-20  0:57           ` Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 05/15] bpf: Allow storing percpu " Kumar Kartikeya Dwivedi
2022-03-19 18:30   ` Alexei Starovoitov
2022-03-19 19:04     ` Kumar Kartikeya Dwivedi
2022-03-19 21:26       ` Alexei Starovoitov
2022-03-19 21:45         ` Kumar Kartikeya Dwivedi
2022-03-19 23:01           ` Alexei Starovoitov
2022-03-17 11:59 ` [PATCH bpf-next v2 06/15] bpf: Allow storing user " Kumar Kartikeya Dwivedi
2022-03-19 18:28   ` Alexei Starovoitov
2022-03-19 19:02     ` Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 07/15] bpf: Prevent escaping of kptr loaded from maps Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 08/15] bpf: Adapt copy_map_value for multiple offset case Kumar Kartikeya Dwivedi
2022-03-19 18:34   ` Alexei Starovoitov
2022-03-19 19:06     ` Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 09/15] bpf: Always raise reference in btf_get_module_btf Kumar Kartikeya Dwivedi
2022-03-19 18:43   ` Alexei Starovoitov
2022-03-20 13:11   ` [bpf] 9a707eb02e: BUG:kernel_NULL_pointer_dereference,address kernel test robot
2022-03-20 13:11     ` kernel test robot
2022-03-17 11:59 ` [PATCH bpf-next v2 10/15] bpf: Populate pairs of btf_id and destructor kfunc in btf Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 11/15] bpf: Wire up freeing of referenced kptr Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 12/15] bpf: Teach verifier about kptr_get kfunc helpers Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 13/15] libbpf: Add kptr type tag macros to bpf_helpers.h Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 14/15] selftests/bpf: Add C tests for kptr Kumar Kartikeya Dwivedi
2022-03-17 11:59 ` [PATCH bpf-next v2 15/15] selftests/bpf: Add verifier " Kumar Kartikeya Dwivedi
2022-03-19 18:50 ` [PATCH bpf-next v2 00/15] Introduce typed pointer support in BPF maps patchwork-bot+netdevbpf

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=20220319213054.e27i6saz73s7snsi@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=memxor@gmail.com \
    --cc=toke@redhat.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.