Re: [PATCH bpf-next 2/3] libbpf: Support configurable pinning of maps from BTF annotations

Andrii Nakryiko [off-list ref] writes:

quoted

quoted

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