From patchwork Mon Jan 23 17:15:04 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Vernet X-Patchwork-Id: 47262 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1722979wrn; Mon, 23 Jan 2023 09:20:41 -0800 (PST) X-Google-Smtp-Source: AMrXdXt6XyRiLKirbM6FIhwyOy7zAReKlsyD9mU0YJlyEHLV0G4rH1MaZIhErMlinnuBVPAXjaqA X-Received: by 2002:a05:6402:f07:b0:493:b55d:d7f2 with SMTP id i7-20020a0564020f0700b00493b55dd7f2mr31104881eda.14.1674494441495; Mon, 23 Jan 2023 09:20:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674494441; cv=none; d=google.com; s=arc-20160816; b=AWE+Cna6yTP7IVJtjOrCw+L1Mebs68oRpxgRgIGaXyMpuMgYJuk/S4ddZ0XQnZnIiJ Ru3r4GYl/MnguHRz5/+Xi0Qaa4YQfnNwieclew9oiGCXSTp7c3rDGL/1ivRpKL1SqCTg rTUPBfb9h9PY3C+iyVhUhSoI3yb1LkfPJy60N+g26LmzfL5Oihbaeuh9GN5gEKlHlPVF 18NPmIPw2my6Uz7m5L963Q+C2RdLWMelNdnMUmEHx4hkwWlhU8IaemA5Pbmb1sTs3hQE CYMr91H2BAxgLlRRqB3rqT0OsLNr0JyZoXbLSkfoKvr8UwkOVtHD9rf1P65tb6zrcJva N2+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=xCvkxNfOd/aJ/4NyFm02XVnNNOSaCLc/2W9e18Wtpm0=; b=ESMterBlfNAoYOv9gXKay9WiFk2THIG2+uxzikFyN4ZO9dcUbKUJurqb7WO+WmB9WK fOzOOTZiAYw1vRlAWPWuwNJZHLVPPlwDAJD+d/+RMf0eOu6VhcKtIGwOUN9GGJNlgU5E nu/YYNCZwQnVzT1fB9jY1AA0JMy7EAAjK6qa8U6Wg50J1ryItFYkaAB6B4RRIxUhJR9r X0enwVK5wcyhDwmUcNNCWB8WaZCvhZQwetHeI+49yyNktiDfp4ogUx/etT751/QcK4yy otetpx6TA4BMgcNBi9VEOcckE6VSL1vJzwd5aP90RpHcebMQpEXiLEQg0sv53memvFo0 8siQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f23-20020a50d557000000b0049f20f495f1si419507edj.366.2023.01.23.09.20.18; Mon, 23 Jan 2023 09:20:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233366AbjAWRP3 (ORCPT + 99 others); Mon, 23 Jan 2023 12:15:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232714AbjAWRPX (ORCPT ); Mon, 23 Jan 2023 12:15:23 -0500 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26FBF2BF38; Mon, 23 Jan 2023 09:15:16 -0800 (PST) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-4a2f8ad29d5so181294177b3.8; Mon, 23 Jan 2023 09:15:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xCvkxNfOd/aJ/4NyFm02XVnNNOSaCLc/2W9e18Wtpm0=; b=rSnF7pdTefxHrQUrjAJxbn7P8FuthoYjFDhf15CWDsgoJwzLKsKbCS2KXfv8s3S1ZX pKtPUrK6zwnIDosL8l4gw8P4a+oaq2Ep2kVvxoEMlSoFWjraf1QJjPN9XLUjrvr6xuRz Pv+en6w5waxzC34kJt/yAUNIveDKi+rYcYPnrZrLKsyG3onoGJTJ2M4RIq/lu86wWib6 ZIykQu4P6kU1DkRkkPAjiuWWEr0pNrvFDO9A3/gR0/P842eqSkBTnRscUjz5Kwx7nqQH zwOYLXLBcQa3aNKPZ3sEYA+eYVIM2VqAf79y9AueUSy+WBgzy1hIpjLHOrLflHQuq6W/ j7Sg== X-Gm-Message-State: AFqh2kpGxfD2SGHhxXL9ynC85k9Eu4Ecr38WyupHNxiN9t80zQlN+sI8 lXTgIatxXAg85u0MpYm1bzpA/2Z+tTWQ1tLP X-Received: by 2002:a81:1b4c:0:b0:4ed:5f40:b293 with SMTP id b73-20020a811b4c000000b004ed5f40b293mr13140534ywb.1.1674494114895; Mon, 23 Jan 2023 09:15:14 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:93a0]) by smtp.gmail.com with ESMTPSA id f1-20020a05620a280100b00706b6ce386fsm10889646qkp.70.2023.01.23.09.15.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Jan 2023 09:15:14 -0800 (PST) From: David Vernet To: bpf@vger.kernel.org Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@meta.com, john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, memxor@gmail.com Subject: [PATCH bpf-next v2 1/3] bpf: Add BPF_KFUNC macro for defining kfuncs Date: Mon, 23 Jan 2023 11:15:04 -0600 Message-Id: <20230123171506.71995-2-void@manifault.com> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20230123171506.71995-1-void@manifault.com> References: <20230123171506.71995-1-void@manifault.com> MIME-Version: 1.0 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755834683652177625?= X-GMAIL-MSGID: =?utf-8?q?1755834683652177625?= kfuncs are functions defined in the kernel, which may be invoked by BPF programs. They may or may not also be used as regular kernel functions, implying that they may be static (in which case the compiler could e.g. inline it away), or it could have external linkage, but potentially be elided in an LTO build if a function is observed to never be used, and is stripped from the final kernel binary. We therefore require some convenience macro that kfunc developers can use when defining a kfunc, and which will prevent all of the above issues from happening. This is in contrast with what we have today, where some kfunc definitions have "noinline", some have "__used", and others are static and have neither. In addition to providing the obvious correctness benefits, having such a macro also provides an easy way to query for if kfuncs, as Christoph suggested at the kernel maintainers summit (https://lwn.net/Articles/908464/). This is currently possible by grepping for BTF_ID_FLAGS(func, but having something more self describing is useful. Note that checkpatch complains about this patch with the following: ERROR: Macros with multiple statements should be enclosed in a do - while loop +#define BPF_KFUNC(proto) \ + proto; \ + __used noinline proto Given that we're wrapping the function definition and also including its prototype, using do { } while(0) isn't an option. Hopefully it's therefore inappropriate to ignore the warning. Signed-off-by: David Vernet --- include/linux/btf.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/include/linux/btf.h b/include/linux/btf.h index 5f628f323442..593a1c2615e7 100644 --- a/include/linux/btf.h +++ b/include/linux/btf.h @@ -72,6 +72,16 @@ #define KF_DESTRUCTIVE (1 << 6) /* kfunc performs destructive actions */ #define KF_RCU (1 << 7) /* kfunc only takes rcu pointer arguments */ +/* + * Macro for defining a kfunc. This is meant to minimize the amount of + * copy-paste that kfunc authors have to include for correctness so as to avoid + * issues such as the compiler inlining or eliding either a static kfunc, or a + * global kfunc in an LTO build. + */ +#define BPF_KFUNC(proto) \ + proto; \ + __used noinline proto + /* * Return the name of the passed struct, if exists, or halt the build if for * example the structure gets renamed. In this way, developers have to revisit