[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzatAgkOiS2+EpauWsUWymmjM4YRBJcSqYj15Ywk8aP6Lw@mail.gmail.com>
Date: Tue, 22 Oct 2019 10:37:17 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
David Miller <davem@...emloft.net>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/3] libbpf: Store map pin path in struct bpf_map
On Tue, Oct 22, 2019 at 9:08 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> From: Toke Høiland-Jørgensen <toke@...hat.com>
>
> When pinning a map, store the pin path in struct bpf_map so it can be
> re-used later for un-pinning. This simplifies the later addition of per-map
> pin paths.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
> ---
> tools/lib/bpf/libbpf.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index cccfd9355134..b4fdd8ee3bbd 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -226,6 +226,7 @@ struct bpf_map {
> void *priv;
> bpf_map_clear_priv_t clear_priv;
> enum libbpf_map_type libbpf_type;
> + char *pin_path;
> };
>
> struct bpf_secdata {
> @@ -1929,6 +1930,7 @@ int bpf_map__reuse_fd(struct bpf_map *map, int fd)
> if (err)
> goto err_close_new_fd;
> free(map->name);
> + zfree(&map->pin_path);
>
While you are touching this function, can you please also fix error
handling in it? We should store -errno locally on error, before we
call close() which might change errno.
> map->fd = new_fd;
> map->name = new_name;
> @@ -4022,6 +4024,7 @@ int bpf_map__pin(struct bpf_map *map, const char *path)
> return -errno;
> }
>
> + map->pin_path = strdup(path);
if (!map->pin_path) {
err = -errno;
goto err_close_new_fd;
}
> pr_debug("pinned map '%s'\n", path);
>
> return 0;
> @@ -4031,6 +4034,9 @@ int bpf_map__unpin(struct bpf_map *map, const char *path)
> {
> int err;
>
> + if (!path)
> + path = map->pin_path;
This semantics is kind of weird. Given we now remember pin_path,
should we instead check that user-provided path is actually correct
and matches what we stored? Alternatively, bpf_map__unpin() w/o path
argument looks like a cleaner API.
> +
> err = check_path(path);
> if (err)
> return err;
> @@ -4044,6 +4050,7 @@ int bpf_map__unpin(struct bpf_map *map, const char *path)
> if (err != 0)
> return -errno;
> pr_debug("unpinned map '%s'\n", path);
> + zfree(&map->pin_path);
>
> return 0;
> }
> @@ -4088,17 +4095,10 @@ int bpf_object__pin_maps(struct bpf_object *obj, const char *path)
>
> err_unpin_maps:
> while ((map = bpf_map__prev(map, obj))) {
> - char buf[PATH_MAX];
> - int len;
> -
> - len = snprintf(buf, PATH_MAX, "%s/%s", path,
> - bpf_map__name(map));
> - if (len < 0)
> - continue;
> - else if (len >= PATH_MAX)
> + if (!map->pin_path)
> continue;
>
> - bpf_map__unpin(map, buf);
> + bpf_map__unpin(map, NULL);
> }
>
> return err;
> @@ -4248,6 +4248,7 @@ void bpf_object__close(struct bpf_object *obj)
>
> for (i = 0; i < obj->nr_maps; i++) {
> zfree(&obj->maps[i].name);
> + zfree(&obj->maps[i].pin_path);
> if (obj->maps[i].clear_priv)
> obj->maps[i].clear_priv(&obj->maps[i],
> obj->maps[i].priv);
>
Powered by blists - more mailing lists