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 <bpf@vger.kernel.org>, "Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <kafai@fb.com>,
	"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Network Development" <netdev@vger.kernel.org>
Subject: Re: [PATCH bpf-next v4 08/11] libbpf: Update gen_loader to emit BTF_KIND_FUNC relocations
Date: Mon, 20 Sep 2021 17:57:16 -0700	[thread overview]
Message-ID: <CAADnVQKjoCLNYBwDvLjgG9cYxrZyhw1Bgvm0yzH0gUWQLNtZnw@mail.gmail.com> (raw)
In-Reply-To: <20210920141526.3940002-9-memxor@gmail.com>

On Mon, Sep 20, 2021 at 7:15 AM Kumar Kartikeya Dwivedi
<memxor@gmail.com> wrote:
>
> This change updates the BPF syscall loader to relocate BTF_KIND_FUNC
> relocations, with support for weak kfunc relocations. The next commit
> adds bpftool supports to set up the fd_array_sz parameter for light
> skeleton.
>
> A second map for keeping fds is used instead of adding fds to existing
> loader.map because of following reasons:

but it complicates signing bpf progs a lot.

> If reserving an area for map and BTF fds, we would waste the remaining
> of (MAX_USED_MAPS + MAX_KFUNC_DESCS) * sizeof(int), which in most cases
> will be unused by the program. Also, we must place some limit on the
> amount of map and BTF fds a program can possibly open.

That is just (256 + 64)*4 bytes of data. Really not much.
I wouldn't worry about reserving this space.

> If setting gen->fd_array to first map_fd offset, and then just finding
> the offset relative to this (for later BTF fds), such that they can be
> packed without wasting space, we run the risk of unnecessarily running
> out of valid offset for emit_relo stage (for kfuncs), because gen map
> creation and relocation stages are separated by other steps that can add
> lots of data (including bpf_object__populate_internal_map). It is also
> prone to break silently if features are added between map and BTF fd
> emits that possibly add more data (just ~128KB to break BTF fd, since
> insn->off allows for INT16_MAX (32767) * 4 bytes).

I don't follow this logic.

> Both of these issues are compounded by the fact that data map is shared
> by all programs, so it is easy to end up with invalid offset for BTF fd.

I don't follow this either. There is only one map and one program.
What sharing are you talking about?

  reply	other threads:[~2021-09-21  1:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 14:15 [PATCH bpf-next v4 00/11] Support kernel module function calls from eBPF Kumar Kartikeya Dwivedi
2021-09-20 14:15 ` [PATCH bpf-next v4 01/11] bpf: Introduce BPF support for kernel module function calls Kumar Kartikeya Dwivedi
2021-09-20 14:15 ` [PATCH bpf-next v4 02/11] bpf: Be conservative while processing invalid kfunc calls Kumar Kartikeya Dwivedi
2021-09-20 14:15 ` [PATCH bpf-next v4 03/11] bpf: btf: Introduce helpers for dynamic BTF set registration Kumar Kartikeya Dwivedi
2021-09-20 14:15 ` [PATCH bpf-next v4 04/11] tools: Allow specifying base BTF file in resolve_btfids Kumar Kartikeya Dwivedi
2021-09-20 14:15 ` [PATCH bpf-next v4 05/11] bpf: Enable TCP congestion control kfunc from modules Kumar Kartikeya Dwivedi
2021-09-21 22:18   ` Andrii Nakryiko
2021-09-21 22:23     ` Kumar Kartikeya Dwivedi
2021-09-21 23:02       ` Andrii Nakryiko
2021-09-20 14:15 ` [PATCH bpf-next v4 06/11] libbpf: Support kernel module function calls Kumar Kartikeya Dwivedi
2021-09-21 22:41   ` Andrii Nakryiko
2021-09-24 23:54     ` Kumar Kartikeya Dwivedi
2021-09-25  0:30       ` Andrii Nakryiko
2021-09-20 14:15 ` [PATCH bpf-next v4 07/11] libbpf: Resolve invalid weak kfunc calls with imm = 0, off = 0 Kumar Kartikeya Dwivedi
2021-09-21 22:47   ` Andrii Nakryiko
2021-09-20 14:15 ` [PATCH bpf-next v4 08/11] libbpf: Update gen_loader to emit BTF_KIND_FUNC relocations Kumar Kartikeya Dwivedi
2021-09-21  0:57   ` Alexei Starovoitov [this message]
2021-09-21  4:50     ` Kumar Kartikeya Dwivedi
2021-09-21 19:04       ` Alexei Starovoitov
2021-09-21 22:25         ` Kumar Kartikeya Dwivedi
2021-09-20 14:15 ` [PATCH bpf-next v4 09/11] tools: bpftool: Add separate fd_array map support for light skeleton Kumar Kartikeya Dwivedi
2021-09-20 14:15 ` [PATCH bpf-next v4 10/11] libbpf: Fix skel_internal.h to set errno on loader retval < 0 Kumar Kartikeya Dwivedi
2021-09-20 14:15 ` [PATCH bpf-next v4 11/11] bpf: selftests: Add selftests for module kfunc support Kumar Kartikeya Dwivedi
2021-09-21 23:00   ` Andrii Nakryiko
2021-09-21 23:13     ` Kumar Kartikeya Dwivedi
2021-09-21 23:28       ` Kumar Kartikeya Dwivedi
2021-09-22  0:03       ` Andrii Nakryiko
2021-09-22  6:06         ` Kumar Kartikeya Dwivedi
2021-09-22 18:24           ` Alexei Starovoitov
2021-09-21  0:29 ` [PATCH bpf-next v4 00/11] Support kernel module function calls from eBPF Andrii Nakryiko
2021-09-21  4:55   ` Kumar Kartikeya Dwivedi

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=CAADnVQKjoCLNYBwDvLjgG9cYxrZyhw1Bgvm0yzH0gUWQLNtZnw@mail.gmail.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=kafai@fb.com \
    --cc=memxor@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=toke@redhat.com \
    --cc=yhs@fb.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.