| Message ID | 20200729230520.693207-1-andriin@fb.com |
|---|---|
| Headers | show |
| Series | BPF link force-detach support | expand |
Andrii Nakryiko <andriin@fb.com> writes: > This patch set adds new BPF link operation, LINK_DETACH, allowing processes > with BPF link FD to force-detach it from respective BPF hook, similarly how > BPF link is auto-detached when such BPF hook (e.g., cgroup, net_device, netns, > etc) is removed. This facility allows admin to forcefully undo BPF link > attachment, while process that created BPF link in the first place is left > intact. > > Once force-detached, BPF link stays valid in the kernel as long as there is at > least one FD open against it. It goes into defunct state, just like > auto-detached BPF link. > > bpftool also got `link detach` command to allow triggering this in > non-programmatic fashion. I know this was already merged, but just wanted to add a belated 'thanks for adding this'! > Cc: Toke Høiland-Jørgensen <toke@redhat.com> BTW, I've noticed that you tend to drop Ccs on later versions of your patch series (had to go and lookup v2 of this to check that it was in fact merged). Is that intentional? :) -Toke
On Mon, Aug 10, 2020 at 8:01 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Andrii Nakryiko <andriin@fb.com> writes: > > > This patch set adds new BPF link operation, LINK_DETACH, allowing processes > > with BPF link FD to force-detach it from respective BPF hook, similarly how > > BPF link is auto-detached when such BPF hook (e.g., cgroup, net_device, netns, > > etc) is removed. This facility allows admin to forcefully undo BPF link > > attachment, while process that created BPF link in the first place is left > > intact. > > > > Once force-detached, BPF link stays valid in the kernel as long as there is at > > least one FD open against it. It goes into defunct state, just like > > auto-detached BPF link. > > > > bpftool also got `link detach` command to allow triggering this in > > non-programmatic fashion. > > I know this was already merged, but just wanted to add a belated 'thanks > for adding this'! > You are welcome! > > Cc: Toke Høiland-Jørgensen <toke@redhat.com> > > BTW, I've noticed that you tend to drop Ccs on later versions of your > patch series (had to go and lookup v2 of this to check that it was in > fact merged). Is that intentional? :) Hm.. not sure about whether I tend to do that. But in this it was intentional and I dropped you from CC because I've seen enough reminders about your vacation, didn't need more ;) In general, though, I try to keep CC list short, otherwise vger blocks my patches. People directly CC'd get them, but they never appear on bpf@vger mailing list. So it probably happened a few times where I started off with longer CC and had to drop people from it just to get my patches into patchworks. > > -Toke >
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes: >> BTW, I've noticed that you tend to drop Ccs on later versions of your >> patch series (had to go and lookup v2 of this to check that it was in >> fact merged). Is that intentional? :) > > Hm.. not sure about whether I tend to do that. But in this it was > intentional and I dropped you from CC because I've seen enough > reminders about your vacation, didn't need more ;) Haha, that's fair ;) > In general, though, I try to keep CC list short, otherwise vger blocks > my patches. People directly CC'd get them, but they never appear on > bpf@vger mailing list. So it probably happened a few times where I > started off with longer CC and had to drop people from it just to get > my patches into patchworks. Ah, I have had that happen to me (patches not showing up on vger), but had no idea that could be related to a long Cc list. Good to know! And thanks for the explanation - it's not a huge issue for me (I do generally keep up with netdev@ and bpf@ although as you can no doubt imagine I'm a wee bit behind right now), was just wondering... -Toke
This patch set adds new BPF link operation, LINK_DETACH, allowing processes with BPF link FD to force-detach it from respective BPF hook, similarly how BPF link is auto-detached when such BPF hook (e.g., cgroup, net_device, netns, etc) is removed. This facility allows admin to forcefully undo BPF link attachment, while process that created BPF link in the first place is left intact. Once force-detached, BPF link stays valid in the kernel as long as there is at least one FD open against it. It goes into defunct state, just like auto-detached BPF link. bpftool also got `link detach` command to allow triggering this in non-programmatic fashion. Cc: Toke Høiland-Jørgensen <toke@redhat.com> Andrii Nakryiko (5): bpf: add support for forced LINK_DETACH command libbpf: add bpf_link detach APIs selftests/bpf: add link detach tests for cgroup, netns, and xdp bpf_links tools/bpftool: add `link detach` subcommand tools/bpftool: add documentation and bash-completion for `link detach` include/linux/bpf.h | 1 + include/uapi/linux/bpf.h | 5 ++ kernel/bpf/cgroup.c | 15 +++++- kernel/bpf/net_namespace.c | 8 +++ kernel/bpf/syscall.c | 26 ++++++++++ net/core/dev.c | 11 +++- .../bpftool/Documentation/bpftool-link.rst | 8 +++ tools/bpf/bpftool/bash-completion/bpftool | 4 +- tools/bpf/bpftool/link.c | 35 ++++++++++++- tools/include/uapi/linux/bpf.h | 5 ++ tools/lib/bpf/bpf.c | 10 ++++ tools/lib/bpf/bpf.h | 2 + tools/lib/bpf/libbpf.c | 5 ++ tools/lib/bpf/libbpf.h | 1 + tools/lib/bpf/libbpf.map | 2 + .../selftests/bpf/prog_tests/cgroup_link.c | 20 +++++++- .../selftests/bpf/prog_tests/sk_lookup.c | 51 +++++++++---------- .../selftests/bpf/prog_tests/xdp_link.c | 14 +++++ tools/testing/selftests/bpf/testing_helpers.c | 14 +++++ tools/testing/selftests/bpf/testing_helpers.h | 3 ++ 20 files changed, 206 insertions(+), 34 deletions(-)