From: Anton Protopopov <aspsk@isovalent.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH v4 bpf-next 3/7] bpf: add fd_array_cnt attribute for prog_load
Date: Thu, 12 Dec 2024 17:17:30 +0000 [thread overview]
Message-ID: <Z1saqkRqbAc+bMWp@eis> (raw)
In-Reply-To: <CAEf4Bza6i3nda+7XPcfmVEckwGfmvsvPmakf_VQhFHEWoVTh4A@mail.gmail.com>
On 24/12/10 10:18AM, Andrii Nakryiko wrote:
> On Tue, Dec 10, 2024 at 7:57 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Tue, Dec 10, 2024 at 12:56 AM Anton Protopopov <aspsk@isovalent.com> wrote:
> > >
> > > >
> > > > This makes total sense to treat all BPF objects in fd_array the same
> > > > way. With BTFs the problem is that, currently, a btf fd can end up
> > > > either in used_btfs or kfunc_btf_tab. I will take a look at how easy
> > > > it is to merge those two.
> > >
> > > So, currently during program load BTFs are parsed from file
> > > descriptors and are stored in two places: env->used_btfs and
> > > env->prog->aux->kfunc_btf_tab:
> > >
> > > 1) env->used_btfs populated only when a DW load with the
> > > (src_reg == BPF_PSEUDO_BTF_ID) flag set is performed
> > >
> > > 2) kfunc_btf_tab is populated by __find_kfunc_desc_btf(),
> > > and the source is attr->fd_array[offset]. The kfunc_btf_tab is
> > > sorted by offset to allow faster search
> > >
> > > So, to merge them something like this might be done:
> > >
> > > 1) If fd_array_cnt != 0, then on load create a [sorted by offset]
> > > table "used_btfs", formatted similar to kfunc_btf_tab in (2)
> > > above.
> > >
> > > 2) On program load change (1) to add a btf to this new sorted
> > > used_btfs. As there is no corresponding offset, just use
> > > offset=-1 (not literally like this, as bsearch() wants unique
> > > keys, so by offset=-1 an array of btfs, aka, old used_maps,
> > > should be stored)
> > >
> > > Looks like this, conceptually, doesn't change things too much: kfuncs
> > > btfs will still be searchable in log(n) time, the "normal" btfs will
> > > still be searched in used_btfs in linear time.
> > >
> > > (The other way is to just allow kfunc btfs to be loaded from fd_array
> > > if fd_array_cnt != 0, as it is done now, but as you've mentioned
> > > before, you had other use cases in mind, so this won't work.)
> >
> > This is getting a bit too complex.
> > I think Andrii is asking to keep BTFs if they are in fd_array.
> > No need to combine kfunc_btf_tab and used_btfs.
> > I think adding BTFs from fd_array to prog->aux->used_btfs
> > should do it.
>
> Exactly, no need to do major changes, let's just add those BTFs into
> used_btfs, that's all.
Added. However, I have a question here: how to add proper selftests? The btfs
listed in env->used_btfs are later copied to prog->aux->used_btfs, and are
never actually exposed to user-space in any way. So, one test I can think of is
* passing a btf fd in fd_array on prog load
* closing this btf fd and checking that id exists before closing the program
(requires to wait until rcu sync to be sure that the btf wasn't destroyed,
but still is refcounted)
Is this enough?
(I assume exposing used_btfs to user-space is also out of scope of this patch
set, right?)
next prev parent reply other threads:[~2024-12-12 17:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 13:50 [PATCH v4 bpf-next 0/7] Add fd_array_cnt attribute for BPF_PROG_LOAD Anton Protopopov
2024-12-03 13:50 ` [PATCH v4 bpf-next 1/7] bpf: add a __btf_get_by_fd helper Anton Protopopov
2024-12-03 21:25 ` Andrii Nakryiko
2024-12-04 10:42 ` Anton Protopopov
2024-12-04 17:58 ` Andrii Nakryiko
2024-12-05 8:33 ` Anton Protopopov
2024-12-03 13:50 ` [PATCH v4 bpf-next 2/7] bpf: move map/prog compatibility checks Anton Protopopov
2024-12-03 13:50 ` [PATCH v4 bpf-next 3/7] bpf: add fd_array_cnt attribute for prog_load Anton Protopopov
2024-12-03 21:25 ` Andrii Nakryiko
2024-12-04 12:22 ` Anton Protopopov
2024-12-04 18:08 ` Andrii Nakryiko
2024-12-05 8:41 ` Anton Protopopov
2024-12-10 8:58 ` Anton Protopopov
2024-12-10 15:57 ` Alexei Starovoitov
2024-12-10 18:18 ` Andrii Nakryiko
2024-12-12 17:17 ` Anton Protopopov [this message]
2024-12-12 17:39 ` Andrii Nakryiko
2024-12-10 18:19 ` Andrii Nakryiko
2024-12-12 17:26 ` Anton Protopopov
2024-12-03 13:50 ` [PATCH v4 bpf-next 4/7] libbpf: prog load: allow to use fd_array_cnt Anton Protopopov
2024-12-03 21:26 ` Andrii Nakryiko
2024-12-03 13:50 ` [PATCH v4 bpf-next 5/7] selftests/bpf: Add tests for fd_array_cnt Anton Protopopov
2024-12-03 21:27 ` Andrii Nakryiko
2024-12-04 12:28 ` Anton Protopopov
2024-12-04 18:10 ` Andrii Nakryiko
2024-12-03 13:50 ` [PATCH v4 bpf-next 6/7] bpf: fix potential error return Anton Protopopov
2024-12-03 21:26 ` Andrii Nakryiko
2024-12-04 10:49 ` Anton Protopopov
2024-12-03 13:50 ` [PATCH v4 bpf-next 7/7] selftest/bpf: replace magic constants by macros Anton Protopopov
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=Z1saqkRqbAc+bMWp@eis \
--to=aspsk@isovalent.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=bpf@vger.kernel.org \
/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