From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
David Miller <davem@davemloft.net>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 2/3] libbpf: Support configurable pinning of maps from BTF annotations
Date: Wed, 23 Oct 2019 15:05:18 +0200 [thread overview]
Message-ID: <87a79rmx2p.fsf@toke.dk> (raw)
In-Reply-To: <6c0e6ebf-aebc-5e80-0e32-aa81857f3a74@iogearbox.net>
> You are worried about the case where an application should be able to
> unpin the map before loading a new one so it doesn't get reused?
No, I'm worried about the opposite: Someone running (the equivalent of)
'ip link set dev eth0 xdp off', and then wondering why all resources
aren't freed.
I do believe that the common case could be solved by a logic similar to
the one I proposed, though:
>> 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?
next prev parent reply other threads:[~2019-10-23 13:05 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
2019-10-23 12:30 ` Daniel Borkmann
2019-10-23 13:05 ` Toke Høiland-Jørgensen [this message]
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 \
--in-reply-to=87a79rmx2p.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.