linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] libbpf: fix the name of a reused map
@ 2022-07-11 10:25 anquan.wu
  2022-07-11 21:51 ` Andrii Nakryiko
  0 siblings, 1 reply; 2+ messages in thread
From: anquan.wu @ 2022-07-11 10:25 UTC (permalink / raw)
  To: ast, daniel, andrii, martin.lau, john.fastabend; +Cc: linux-kernel, anquan.wu

BPF map name was limited to BPF_OBJ_NAME_LEN.
If a map name is defined as being longer than BPF_OBJ_NAME_LEN,
it will be truncated to BPF_OBJ_NAME_LEN
when a userspace program calls libbpf to create the map.
A pinned map also generates a path in the /sys.
If the previous program wanted to reuse the map,it can not get bpf_map
by name, because the name of the map is only partially the same as
the name which get from pinned path.

The syscall information below show that map name
"process_pinned_map" is truncated to process_pinned_"

bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/process_pinned_map",
bpf_fd=0, file_flags=0}, 144) = -1 ENOENT (No such file or directory)

bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=4,
max_entries=1024, map_flags=0, inner_map_fd=0, map_name="process_pinned_",
map_ifindex=0, btf_fd=3, btf_key_type_id=6, btf_value_type_id=10,
btf_vmlinux_value_type_id=0}, 72) = 4

This patch check that if the name of pinned map are the same as the
actual name for the first (BPF_OBJ_NAME_LEN - 1),
bpf map still uses the name which is included in bpf object.

Signed-off-by: anquan.wu <leiqi96@hotmail.com>
---
 tools/lib/bpf/libbpf.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index e89cc9c885b3..5ad52a8accd1 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -4328,6 +4328,7 @@ int bpf_map__reuse_fd(struct bpf_map *map, int fd)
 {
 	struct bpf_map_info info = {};
 	__u32 len = sizeof(info);
+	__u32 name_len;
 	int new_fd, err;
 	char *new_name;
 
@@ -4337,7 +4338,12 @@ int bpf_map__reuse_fd(struct bpf_map *map, int fd)
 	if (err)
 		return libbpf_err(err);
 
-	new_name = strdup(info.name);
+	name_len = strlen(info.name);
+	if ((BPF_OBJ_NAME_LEN - 1) == name_len && !strncmp(map->name, info.name, name_len))
+		new_name = strdup(map->name);
+	else
+		new_name = strdup(info.name);
+
 	if (!new_name)
 		return libbpf_err(-errno);
 
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] libbpf: fix the name of a reused map
  2022-07-11 10:25 [PATCH] libbpf: fix the name of a reused map anquan.wu
@ 2022-07-11 21:51 ` Andrii Nakryiko
  0 siblings, 0 replies; 2+ messages in thread
From: Andrii Nakryiko @ 2022-07-11 21:51 UTC (permalink / raw)
  To: anquan.wu
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, martin.lau,
	john fastabend, open list

On Mon, Jul 11, 2022 at 3:25 AM anquan.wu <leiqi96@hotmail.com> wrote:
>
> BPF map name was limited to BPF_OBJ_NAME_LEN.
> If a map name is defined as being longer than BPF_OBJ_NAME_LEN,
> it will be truncated to BPF_OBJ_NAME_LEN
> when a userspace program calls libbpf to create the map.
> A pinned map also generates a path in the /sys.
> If the previous program wanted to reuse the map,it can not get bpf_map
> by name, because the name of the map is only partially the same as
> the name which get from pinned path.
>
> The syscall information below show that map name
> "process_pinned_map" is truncated to process_pinned_"
>
> bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/process_pinned_map",
> bpf_fd=0, file_flags=0}, 144) = -1 ENOENT (No such file or directory)
>
> bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=4,
> max_entries=1024, map_flags=0, inner_map_fd=0, map_name="process_pinned_",
> map_ifindex=0, btf_fd=3, btf_key_type_id=6, btf_value_type_id=10,
> btf_vmlinux_value_type_id=0}, 72) = 4
>
> This patch check that if the name of pinned map are the same as the
> actual name for the first (BPF_OBJ_NAME_LEN - 1),
> bpf map still uses the name which is included in bpf object.
>
> Signed-off-by: anquan.wu <leiqi96@hotmail.com>

please use your complete and capitalized name in Signed-off-by

Overall, looks good, I have a few stylistical nits, see below. But
also you forgot to cc bpf@vger.kernel.org, please send v2 and don't
forget to add mailing list. Without that our CI can't test your patch
properly.


> ---
>  tools/lib/bpf/libbpf.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index e89cc9c885b3..5ad52a8accd1 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -4328,6 +4328,7 @@ int bpf_map__reuse_fd(struct bpf_map *map, int fd)
>  {
>         struct bpf_map_info info = {};
>         __u32 len = sizeof(info);
> +       __u32 name_len;

nit: __u32 len = sizeof(info), name_len;

>         int new_fd, err;
>         char *new_name;
>
> @@ -4337,7 +4338,12 @@ int bpf_map__reuse_fd(struct bpf_map *map, int fd)
>         if (err)
>                 return libbpf_err(err);
>
> -       new_name = strdup(info.name);
> +       name_len = strlen(info.name);
> +       if ((BPF_OBJ_NAME_LEN - 1) == name_len && !strncmp(map->name, info.name, name_len))

nit, unnecessary () around BPF_OBJ_NAME_LEN, plus the order is a bit
weird. I also have general preference with strncmp/strcmp to compare
against zero explicitly, so can you rewrite this as:

if (name_len == BPF_OBJ_NAME_LEN - 1 && strncmp(map->name, info.name,
name_len) == 0)

?

> +               new_name = strdup(map->name);
> +       else
> +               new_name = strdup(info.name);
> +
>         if (!new_name)
>                 return libbpf_err(-errno);
>
> --
> 2.32.0
>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-07-11 21:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-11 10:25 [PATCH] libbpf: fix the name of a reused map anquan.wu
2022-07-11 21:51 ` Andrii Nakryiko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).