From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66630C43603 for ; Thu, 19 Dec 2019 22:41:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 38C1424676 for ; Thu, 19 Dec 2019 22:41:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iISSv5wg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726911AbfLSWl3 (ORCPT ); Thu, 19 Dec 2019 17:41:29 -0500 Received: from mail-qk1-f196.google.com ([209.85.222.196]:45862 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726818AbfLSWl2 (ORCPT ); Thu, 19 Dec 2019 17:41:28 -0500 Received: by mail-qk1-f196.google.com with SMTP id x1so6016393qkl.12 for ; Thu, 19 Dec 2019 14:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=70AoCw7gR/ANBDfALYHWvs5rEExyH90S86seDrQcu0Y=; b=iISSv5wgM/XpaX0RDpzDfmT0RcdgGp7sB4jESAawd+o0BoRU4w5RPkuV4fOfRStLe7 DJ7LKxPoJeHjufMLvNY7l2iP/rWQTXC4rDpoj/o7q/ET2qTfO0v6cS+rJ0jBCBtvqKAQ /A5tQY01WrB4m8Vdz5B3zlPjKLj/gUYD14aInA7aEy2S0+aZAOrVSaR/PsD7NgTVZ2OU 2eF0uSen9xQSLmFxENXk7rK97jn2OlV0gXVUVGVYI1tX7j16TNo0oY0GIrEdKPaRBW5q DAmFPqLNLz8jMnzS9XbaEuT34j3tpVaTFoiibdCcAJZUCuIJzYaM2/oGUcdIb2djBgFN 9ekg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=70AoCw7gR/ANBDfALYHWvs5rEExyH90S86seDrQcu0Y=; b=qdWKHWzk3wqw91md/vvX5XcdmRv0xA5udvhOvZGv0hOs+7Hn6XHt3uaXbwhPS6mKnI QSosvnQ6pq7a7LluV1FOEFRKtygPyGBDu+GO6DOGLluHFxuq5x6VkLoRVe7ZgTGtvTQB pHvhU1xSxqAG/KnJurC5Ua+pZaPTla40ydLyfcoxQOWj0v5VRSWTS47OcbhTPUGOWXfV i5vuApI/CFyPlCvkiTkuA1UGwr7V3IVYwBqRNV7HwRwKT4mbAy7GEa+W1X0OHHPqGUKm akQnXZ79nP7JeqCruOGq/RKfAzPy9ttK3aAjyvVNaLkgF9MVGZpavoUZnS7Tn8E05zUX omgA== X-Gm-Message-State: APjAAAW51HzRagoZfCIrkU51eXq9kNAvwyQjV1dTFyDQf4kkx5dLMyUl F//zlZ0EoqwnkxQ8CqF/9FOAsa05SMtcFxrbkUNAZjBt X-Google-Smtp-Source: APXvYqyRQJeCjtep4nRdALFOOawBRVV3x8DY6cEgZnMwmYXj2Jt/PtgPgUJ3CS/LNaCYOiLN2LXIeNyTNQBIheIi870= X-Received: by 2002:a05:620a:5ae:: with SMTP id q14mr10865787qkq.437.1576795287863; Thu, 19 Dec 2019 14:41:27 -0800 (PST) MIME-Version: 1.0 References: <30cd850044a0057bdfcaaf154b7d2f39850ba813.1576741281.git.rdna@fb.com> In-Reply-To: <30cd850044a0057bdfcaaf154b7d2f39850ba813.1576741281.git.rdna@fb.com> From: Andrii Nakryiko Date: Thu, 19 Dec 2019 14:41:16 -0800 Message-ID: Subject: Re: [PATCH v4 bpf-next 3/6] bpf: Support replacing cgroup-bpf program in MULTI mode To: Andrey Ignatov Cc: bpf , Alexei Starovoitov , Daniel Borkmann , Martin Lau , Andrii Nakryiko , Kernel Team Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, Dec 18, 2019 at 11:45 PM Andrey Ignatov wrote: > > The common use-case in production is to have multiple cgroup-bpf > programs per attach type that cover multiple use-cases. Such programs > are attached with BPF_F_ALLOW_MULTI and can be maintained by different > people. > > Order of programs usually matters, for example imagine two egress > programs: the first one drops packets and the second one counts packets. > If they're swapped the result of counting program will be different. > > It brings operational challenges with updating cgroup-bpf program(s) > attached with BPF_F_ALLOW_MULTI since there is no way to replace a > program: > > * One way to update is to detach all programs first and then attach the > new version(s) again in the right order. This introduces an > interruption in the work a program is doing and may not be acceptable > (e.g. if it's egress firewall); > > * Another way is attach the new version of a program first and only then > detach the old version. This introduces the time interval when two > versions of same program are working, what may not be acceptable if a > program is not idempotent. It also imposes additional burden on > program developers to make sure that two versions of their program can > co-exist. > > Solve the problem by introducing a "replace" mode in BPF_PROG_ATTACH > command for cgroup-bpf programs being attached with BPF_F_ALLOW_MULTI > flag. This mode is enabled by newly introduced BPF_F_REPLACE attach flag > and bpf_attr.replace_bpf_fd attribute to pass fd of the old program to > replace > > That way user can replace any program among those attached with > BPF_F_ALLOW_MULTI flag without the problems described above. > > Details of the new API: > > * If BPF_F_REPLACE is set but replace_bpf_fd doesn't have valid > descriptor of BPF program, BPF_PROG_ATTACH will return corresponding > error (EINVAL or EBADF). > > * If replace_bpf_fd has valid descriptor of BPF program but such a > program is not attached to specified cgroup, BPF_PROG_ATTACH will > return ENOENT. > > BPF_F_REPLACE is introduced to make the user intent clear, since > replace_bpf_fd alone can't be used for this (its default value, 0, is a > valid fd). BPF_F_REPLACE also makes it possible to extend the API in the > future (e.g. add BPF_F_BEFORE and BPF_F_AFTER if needed). > > Signed-off-by: Andrey Ignatov > Acked-by: Martin KaFai Lau > --- Looks good. Acked-by: Andrii Narkyiko > include/linux/bpf-cgroup.h | 4 +++- > include/uapi/linux/bpf.h | 10 ++++++++++ > kernel/bpf/cgroup.c | 30 ++++++++++++++++++++++++++---- > kernel/bpf/syscall.c | 4 ++-- > kernel/cgroup/cgroup.c | 5 +++-- > tools/include/uapi/linux/bpf.h | 10 ++++++++++ > 6 files changed, 54 insertions(+), 9 deletions(-) > [...]