From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: David Ahern <dsahern@gmail.com>
Cc: Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
Networking <netdev@vger.kernel.org>,
Alexei Starovoitov <ast@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrey Ignatov <rdna@fb.com>, Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link
Date: Mon, 30 Mar 2020 13:20:17 -0700 [thread overview]
Message-ID: <CAEf4BzZpCOCi1QfL0peBRjAOkXRwGEi_DAW4z34Mf3Tv_sbRFw@mail.gmail.com> (raw)
In-Reply-To: <c9f52288-5ea8-a117-8a67-84ba48374d3a@gmail.com>
On Mon, Mar 30, 2020 at 7:49 AM David Ahern <dsahern@gmail.com> wrote:
>
> On 3/29/20 8:59 PM, Andrii Nakryiko wrote:
> > bpf_link abstraction itself was formalized in [0] with justifications for why
> > its semantics is a good fit for attaching BPF programs of various types. This
> > patch set adds bpf_link-based BPF program attachment mechanism for cgroup BPF
> > programs.
> >
> > Cgroup BPF link is semantically compatible with current BPF_F_ALLOW_MULTI
> > semantics of attaching cgroup BPF programs directly. Thus cgroup bpf_link can
> > co-exist with legacy BPF program multi-attachment.
> >
> > bpf_link is destroyed and automatically detached when the last open FD holding
> > the reference to bpf_link is closed. This means that by default, when the
> > process that created bpf_link exits, attached BPF program will be
> > automatically detached due to bpf_link's clean up code. Cgroup bpf_link, like
> > any other bpf_link, can be pinned in BPF FS and by those means survive the
> > exit of process that created the link. This is useful in many scenarios to
> > provide long-living BPF program attachments. Pinning also means that there
> > could be many owners of bpf_link through independent FDs.
> >
> > Additionally, auto-detachmet of cgroup bpf_link is implemented. When cgroup is
> > dying it will automatically detach all active bpf_links. This ensures that
> > cgroup clean up is not delayed due to active bpf_link even despite no chance
> > for any BPF program to be run for a given cgroup. In that sense it's similar
> > to existing behavior of dropping refcnt of attached bpf_prog. But in the case
> > of bpf_link, bpf_link is not destroyed and is still available to user as long
> > as at least one active FD is still open (or if it's pinned in BPF FS).
> >
> > There are two main cgroup-specific differences between bpf_link-based and
> > direct bpf_prog-based attachment.
> >
> > First, as opposed to direct bpf_prog attachment, cgroup itself doesn't "own"
> > bpf_link, which makes it possible to auto-clean up attached bpf_link when user
> > process abruptly exits without explicitly detaching BPF program. This makes
> > for a safe default behavior proven in BPF tracing program types. But bpf_link
> > doesn't bump cgroup->bpf.refcnt as well and because of that doesn't prevent
> > cgroup from cleaning up its BPF state.
> >
> > Second, only owners of bpf_link (those who created bpf_link in the first place
> > or obtained a new FD by opening bpf_link from BPF FS) can detach and/or update
> > it. This makes sure that no other process can accidentally remove/replace BPF
> > program.
> >
> > This patch set also implements LINK_UPDATE sub-command, which allows to
> > replace bpf_link's underlying bpf_prog, similarly to BPF_F_REPLACE flag
> > behavior for direct bpf_prog cgroup attachment. Similarly to LINK_CREATE, it
> > is supposed to be generic command for different types of bpf_links.
> >
>
> The observability piece should go in the same release as the feature.
You mean LINK_QUERY command I mentioned before? Yes, I'm working on
adding it next, regardless if this patch set goes in right now or
later.
next prev parent reply other threads:[~2020-03-30 20:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-30 2:59 [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link Andrii Nakryiko
2020-03-30 2:59 ` [PATCH v3 bpf-next 1/4] bpf: implement bpf_link-based cgroup BPF program attachment Andrii Nakryiko
2020-03-31 0:05 ` Andrey Ignatov
2020-03-31 0:38 ` Alexei Starovoitov
2020-03-31 1:06 ` Andrii Nakryiko
2020-03-30 2:59 ` [PATCH v3 bpf-next 2/4] bpf: implement bpf_prog replacement for an active bpf_cgroup_link Andrii Nakryiko
2020-03-30 3:00 ` [PATCH v3 bpf-next 3/4] libbpf: add support for bpf_link-based cgroup attachment Andrii Nakryiko
2020-03-30 3:00 ` [PATCH v3 bpf-next 4/4] selftests/bpf: test FD-based " Andrii Nakryiko
2020-03-30 14:49 ` [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link David Ahern
2020-03-30 20:20 ` Andrii Nakryiko [this message]
2020-03-30 20:45 ` David Ahern
2020-03-30 20:50 ` Alexei Starovoitov
2020-03-30 22:50 ` Alexei Starovoitov
2020-03-30 23:43 ` David Ahern
2020-03-31 0:32 ` Alexei Starovoitov
2020-03-31 0:57 ` David Ahern
2020-03-31 1:17 ` Alexei Starovoitov
2020-04-01 1:42 ` David Ahern
2020-04-01 2:04 ` Alexei Starovoitov
2020-03-31 3:54 ` Andrii Nakryiko
2020-03-31 16:54 ` David Ahern
2020-03-31 17:03 ` Andrii Nakryiko
2020-03-31 17:11 ` Alexei Starovoitov
2020-03-31 21:51 ` Edward Cree
2020-03-31 22:44 ` David Ahern
2020-04-01 0:45 ` Andrii Nakryiko
2020-04-01 0:22 ` Andrii Nakryiko
2020-04-01 14:26 ` Edward Cree
2020-04-01 17:39 ` Andrii Nakryiko
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=CAEf4BzZpCOCi1QfL0peBRjAOkXRwGEi_DAW4z34Mf3Tv_sbRFw@mail.gmail.com \
--to=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dsahern@gmail.com \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=rdna@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 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).