From: Jiri Olsa <olsajiri@gmail.com>
To: Andrii Nakryiko <andrii@kernel.org>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
martin.lau@kernel.org, kernel-team@meta.com,
Alastair Robertson <ajor@meta.com>,
Jonathan Wiepert <jwiepert@meta.com>
Subject: Re: [PATCH bpf-next 2/3] libbpf: move global data mmap()'ing into bpf_object__load()
Date: Wed, 23 Oct 2024 14:54:32 +0200 [thread overview]
Message-ID: <ZxjyCOWne0qXts5o@krava> (raw)
In-Reply-To: <20241023043908.3834423-3-andrii@kernel.org>
On Tue, Oct 22, 2024 at 09:39:07PM -0700, Andrii Nakryiko wrote:
SNIP
> @@ -5146,11 +5147,43 @@ bpf_object__populate_internal_map(struct bpf_object *obj, struct bpf_map *map)
> if (err) {
> err = -errno;
> cp = libbpf_strerror_r(err, errmsg, sizeof(errmsg));
> - pr_warn("Error freezing map(%s) as read-only: %s\n",
> - map->name, cp);
> + pr_warn("map '%s': failed to freeze as read-only: %s\n",
> + bpf_map__name(map), cp);
> return err;
> }
> }
> +
> + /* Remap anonymous mmap()-ed "map initialization image" as
> + * a BPF map-backed mmap()-ed memory, but preserving the same
> + * memory address. This will cause kernel to change process'
> + * page table to point to a different piece of kernel memory,
> + * but from userspace point of view memory address (and its
> + * contents, being identical at this point) will stay the
> + * same. This mapping will be released by bpf_object__close()
> + * as per normal clean up procedure.
> + */
> + mmap_sz = bpf_map_mmap_sz(map);
> + if (map->def.map_flags & BPF_F_MMAPABLE) {
> + void *mmaped;
> + int prot;
> +
> + if (map->def.map_flags & BPF_F_RDONLY_PROG)
> + prot = PROT_READ;
> + else
> + prot = PROT_READ | PROT_WRITE;
> + mmaped = mmap(map->mmaped, mmap_sz, prot, MAP_SHARED | MAP_FIXED, map->fd, 0);
> + if (mmaped == MAP_FAILED) {
> + err = -errno;
> + pr_warn("map '%s': failed to re-mmap() contents: %d\n",
> + bpf_map__name(map), err);
> + return err;
> + }
> + map->mmaped = mmaped;
> + } else if (map->mmaped) {
> + munmap(map->mmaped, mmap_sz);
> + map->mmaped = NULL;
> + }
this caught my eye because we did not do that in bpf_object__load_skeleton,
makes sense, but why do we mmap *!*BPF_F_MMAPABLE maps in the first place?
jirka
> +
> return 0;
> }
>
> @@ -5467,8 +5500,7 @@ bpf_object__create_maps(struct bpf_object *obj)
> err = bpf_object__populate_internal_map(obj, map);
> if (err < 0)
> goto err_out;
> - }
> - if (map->def.type == BPF_MAP_TYPE_ARENA) {
> + } else if (map->def.type == BPF_MAP_TYPE_ARENA) {
> map->mmaped = mmap((void *)(long)map->map_extra,
> bpf_map_mmap_sz(map), PROT_READ | PROT_WRITE,
> map->map_extra ? MAP_SHARED | MAP_FIXED : MAP_SHARED,
> @@ -13916,46 +13948,11 @@ int bpf_object__load_skeleton(struct bpf_object_skeleton *s)
> for (i = 0; i < s->map_cnt; i++) {
> struct bpf_map_skeleton *map_skel = (void *)s->maps + i * s->map_skel_sz;
> struct bpf_map *map = *map_skel->map;
> - size_t mmap_sz = bpf_map_mmap_sz(map);
> - int prot, map_fd = map->fd;
> - void **mmaped = map_skel->mmaped;
> -
> - if (!mmaped)
> - continue;
> -
> - if (!(map->def.map_flags & BPF_F_MMAPABLE)) {
> - *mmaped = NULL;
> - continue;
> - }
>
> - if (map->def.type == BPF_MAP_TYPE_ARENA) {
> - *mmaped = map->mmaped;
> + if (!map_skel->mmaped)
> continue;
> - }
> -
> - if (map->def.map_flags & BPF_F_RDONLY_PROG)
> - prot = PROT_READ;
> - else
> - prot = PROT_READ | PROT_WRITE;
>
> - /* Remap anonymous mmap()-ed "map initialization image" as
> - * a BPF map-backed mmap()-ed memory, but preserving the same
> - * memory address. This will cause kernel to change process'
> - * page table to point to a different piece of kernel memory,
> - * but from userspace point of view memory address (and its
> - * contents, being identical at this point) will stay the
> - * same. This mapping will be released by bpf_object__close()
> - * as per normal clean up procedure, so we don't need to worry
> - * about it from skeleton's clean up perspective.
> - */
> - *mmaped = mmap(map->mmaped, mmap_sz, prot, MAP_SHARED | MAP_FIXED, map_fd, 0);
> - if (*mmaped == MAP_FAILED) {
> - err = -errno;
> - *mmaped = NULL;
> - pr_warn("failed to re-mmap() map '%s': %d\n",
> - bpf_map__name(map), err);
> - return libbpf_err(err);
> - }
> + *map_skel->mmaped = map->mmaped;
> }
>
> return 0;
> --
> 2.43.5
>
>
next prev parent reply other threads:[~2024-10-23 12:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 4:39 [PATCH bpf-next 0/3] Fix libbpf's bpf_object and BPF subskel interoperability Andrii Nakryiko
2024-10-23 4:39 ` [PATCH bpf-next 1/3] selftests/bpf: fix test_spin_lock_fail.c's global vars usage Andrii Nakryiko
2024-10-23 4:39 ` [PATCH bpf-next 2/3] libbpf: move global data mmap()'ing into bpf_object__load() Andrii Nakryiko
2024-10-23 12:54 ` Jiri Olsa [this message]
2024-10-23 15:59 ` Andrii Nakryiko
2024-10-23 4:39 ` [PATCH bpf-next 3/3] selftests/bpf: validate generic bpf_object and subskel APIs work together Andrii Nakryiko
2024-10-24 5:20 ` [PATCH bpf-next 0/3] Fix libbpf's bpf_object and BPF subskel interoperability 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=ZxjyCOWne0qXts5o@krava \
--to=olsajiri@gmail.com \
--cc=ajor@meta.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jwiepert@meta.com \
--cc=kernel-team@meta.com \
--cc=martin.lau@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