From: "Toke Høiland-Jørgensen" <email@example.com> To: Andrii Nakryiko <firstname.lastname@example.org> Cc: Daniel Borkmann <email@example.com>, Alexei Starovoitov <firstname.lastname@example.org>, Martin KaFai Lau <email@example.com>, Song Liu <firstname.lastname@example.org>, Yonghong Song <email@example.com>, Jesper Dangaard Brouer <firstname.lastname@example.org>, David Miller <email@example.com>, Networking <firstname.lastname@example.org>, bpf <email@example.com> Subject: Re: [PATCH bpf-next 2/3] libbpf: Support configurable pinning of maps from BTF annotations Date: Wed, 23 Oct 2019 10:53:58 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAEf4BzY-buKFadzzAKpCdjAZ+1_UwSpQobdRH7yQn_fFXQYX0w@mail.gmail.com> Andrii Nakryiko <email@example.com> writes: >> > 4. Once pinned, map knows its pinned path, just use that, I don't see >> > any reasonable use case where you'd want to override path just for >> > unpinning. >> >> Well, unpinning may need to re-construct the pin path. E.g., >> applications that exit after loading and are re-run after unloading, >> such as iproute2, probably want to be able to unpin maps. Unfortunately >> I don't think there is a way to get the pin path(s) of an object from >> the kernel, though, is there? That would be kinda neat for implementing >> something like `ip link set dev eth0 xdp off unpin`. > > Hm... It seems to me that if application exits and another instance > starts, it should generate pin path using the same logic, then check > if map is already pinned. Then based on settings, either reuse or > unpin first. Either way, pin_path needs to be calculated from map > attributes, not "guessed" by application. Yeah, ideally. However, the bpf object file may not be available (it's not for iproute2, for instance). I'm not sure there's really anything we *can* do about that, though, other than have the application guess. Unless we add more state to the kernel. Would it make sense to store the fact that a map was auto-pinned as a flag in the kernel map info? That way, an application could read that flag along with the name and go looking in /sys/fs/bpf. Hmm, but I guess it could do that anyway; so maybe what we need is just a "try to find all pinned maps of this program" function? That could then to something like: - Get the maps IDs and names of all maps attached to that program from the kernel. - Look for each map name in /sys/fs/bpf - If a pinned map with the same name exists, compare the IDs, and unlink if they match I don't suppose it'll be possible to do all that in a race-free manner, but that would go for any use of unlink() unless I'm missing something? -Toke
next prev parent reply other threads:[~2019-10-23 8:54 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-22 15:04 [PATCH bpf-next 0/3] libbpf: Support pinning of maps using 'pinning' BTF attribute Toke Høiland-Jørgensen 2019-10-22 15:04 ` [PATCH bpf-next 1/3] libbpf: Store map pin path in struct bpf_map Toke Høiland-Jørgensen 2019-10-22 17:37 ` Andrii Nakryiko 2019-10-22 18:13 ` Toke Høiland-Jørgensen 2019-10-22 18:23 ` Andrii Nakryiko 2019-10-22 18:45 ` Toke Høiland-Jørgensen 2019-10-22 18:49 ` Andrii Nakryiko 2019-10-22 19:06 ` Toke Høiland-Jørgensen 2019-10-23 4:43 ` Andrii Nakryiko 2019-10-22 15:04 ` [PATCH bpf-next 2/3] libbpf: Support configurable pinning of maps from BTF annotations Toke Høiland-Jørgensen 2019-10-22 18:20 ` Andrii Nakryiko 2019-10-22 18:57 ` Toke Høiland-Jørgensen 2019-10-23 4:40 ` Andrii Nakryiko 2019-10-23 8:53 ` Toke Høiland-Jørgensen [this message] 2019-10-23 12:30 ` Daniel Borkmann 2019-10-23 13:05 ` Toke Høiland-Jørgensen 2019-10-22 15:04 ` [PATCH bpf-next 3/3] libbpf: Add pin option to automount BPF filesystem before pinning Toke Høiland-Jørgensen 2019-10-22 18:28 ` Andrii Nakryiko 2019-10-22 19:04 ` Toke Høiland-Jørgensen 2019-10-23 4:58 ` Andrii Nakryiko 2019-10-23 8:58 ` Toke Høiland-Jørgensen
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH bpf-next 2/3] libbpf: Support configurable pinning of maps from BTF annotations' \ /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
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).