BPF List
 help / color / mirror / Atom feed
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
> 
> 

  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