Message ID | 20230106195130.1216841-1-void@manifault.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp998898wrt; Fri, 6 Jan 2023 11:53:34 -0800 (PST) X-Google-Smtp-Source: AMrXdXuT52rHN8NHtN0fg7v/5motB6niFWcCszwG6aGprmmOSHNi2uEC8GtL+1BmrCmkOsKtQ/Vo X-Received: by 2002:a17:906:27d4:b0:7c1:337e:575b with SMTP id k20-20020a17090627d400b007c1337e575bmr48459409ejc.66.1673034813849; Fri, 06 Jan 2023 11:53:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673034813; cv=none; d=google.com; s=arc-20160816; b=YHfXOh15uVO6tGPk34LLkSLyM8UR6Wic2dzOIWjPzMDbIZU61ymiuO6JjwSjQYISVR yvKXHYwM+jeVQkQ4yz290CN+GcutjmARuJetH9z9F29EqdXINOEs4qKZNNgJBPn72mDQ /RUsRockHMM2Inh6bVuY2fnCIs2x4I+ilHv0BzWJmvLiDfVkfa6NCmFdifV3QAu6kYpH fmWYm3wfe6tZIglW1GBVeyFwAflBgmPx5p6Ekh26j0QpR6ibeoHLX3gNRXDQaTGJlSan urJ3G05vp0GVby8cZaaNIhL9o43VbdQplxuPqbyNTn6jJ02wMqPTSVz/FaSEZa9wPMls Ac/g== 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 :message-id:date:subject:cc:to:from; bh=dQtsw9lY0h7dyAESUotPsd50CIIa1Z4iwSP2XIRccpE=; b=iaJuH3aN0YUWL4jrme1qVfdGiANGfkTH3R7CUeJNSAnS9zMJ48F96ttLrZgvKgM9d0 ORYd1EO5w7lkShdvvrdbIqHNLG6JxLspP5OdnyIGZ0/T6rpYCnmD5dtKm4zZ2skPLdDw CrOs30scy93O9GKS3F415Rvl/3+eyupt1wHWZsrG7XfcuJMetogPJ8447J0XG5/ajIQ8 qQwCEBG9uaOtw9dB1XB21AEFpQ4um9vDaAJWqlQE/27EjfVU0DdJ90LCUSoGmJZnx0L5 mhrYI8BR+07t/QITOaRPmNPSpAYtEHGaDTFQLTA6jqD1Am5rX54WJxE3OtMTmdu3LMql zvzw== 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 di4-20020a170906730400b007ae814af6aasi2774007ejc.87.2023.01.06.11.53.10; Fri, 06 Jan 2023 11:53:33 -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 S235939AbjAFTv7 (ORCPT <rfc822;tmhikaru@gmail.com> + 99 others); Fri, 6 Jan 2023 14:51:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229619AbjAFTvz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 6 Jan 2023 14:51:55 -0500 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6580D81C1C; Fri, 6 Jan 2023 11:51:40 -0800 (PST) Received: by mail-qt1-f176.google.com with SMTP id v14so3004283qtq.3; Fri, 06 Jan 2023 11:51:40 -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:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dQtsw9lY0h7dyAESUotPsd50CIIa1Z4iwSP2XIRccpE=; b=Jo/I9RBMWYV4cnAHViXi/hUC0UxAsxA9NQu8D89d1skuaMIwJaBWiCtUG2x3MF5bCD nrK9y3FBapH/3ler5h1w/m+LbWBm0mgHSD1jgP4UtCX+DgDzFKl0e/p4oYRLxF5/l/kk QN7+XhvH4xDHNDFMpyoSeofugQLLnZFelxRZe0bwzwdK6m0YAH4VGtJVcJDoE9y7qwmu BiNW2KpP7Vhat+IWutanv7DUXXDF6zxCersho0Jnb1bhCabaZaLtl1YeBinZ9oj5Hufc TJoTEcoPf3eMteho5CKQkyAYX0ibm8n+2rydfUGFy/YEaFKxqB0KhQDGGPr6vCnxwJUt 2K+Q== X-Gm-Message-State: AFqh2kppNIFRXzBe4IP9HYJhHPlofmHoWIO8P+AbV7YlaC37+sNqUsiY d7zPsl8NxwIfikjZkWXwDnnY/MZbpsHOej+U X-Received: by 2002:ac8:4408:0:b0:3a9:8984:1103 with SMTP id j8-20020ac84408000000b003a989841103mr72676216qtn.67.1673034699168; Fri, 06 Jan 2023 11:51:39 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:a6f6]) by smtp.gmail.com with ESMTPSA id bs25-20020ac86f19000000b0039cb59f00fcsm934640qtb.30.2023.01.06.11.51.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Jan 2023 11:51:38 -0800 (PST) From: David Vernet <void@manifault.com> 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 Subject: [PATCH bpf-next 0/3] Annotate kfuncs with new __bpf_kfunc macro Date: Fri, 6 Jan 2023 13:51:27 -0600 Message-Id: <20230106195130.1216841-1-void@manifault.com> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754304152707361978?= X-GMAIL-MSGID: =?utf-8?q?1754304152707361978?= |
Series |
Annotate kfuncs with new __bpf_kfunc macro
|
|
Message
David Vernet
Jan. 6, 2023, 7:51 p.m. UTC
BPF kfuncs are kernel functions that can be invoked by BPF programs. kfuncs can be kernel functions which are also called elsewhere in the main kernel (such as crash_kexec()), or may be functions that are only meant to be used by BPF programs, such as bpf_task_acquire(), and which are not called from anywhere else in the kernel. While thus far we haven't observed any issues such as kfuncs being elided by the compiler, at some point we could easily run into problems such as the following: - static kernel functions that are also used as kfuncs could be inlined and/or elided by the compiler. - BPF-specific kfuncs with external linkage may at some point be elided by the compiler in LTO builds, when it's determined that they aren't called anywhere. To address this, this patch set introduces a new __bpf_kfunc macro which should be added to all kfuncs, and which will protect kfuncs from such problems. Note that some kfuncs kind of try to do this already by specifying noinline or __used. We are inconsistent in how this is applied. __bpf_kfunc should provide a uniform and more-future-proof way to do this. David Vernet (3): bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs bpf: Document usage of the new __bpf_kfunc macro bpf: Add __bpf_kfunc tag to all kfuncs Documentation/bpf/kfuncs.rst | 18 +++++ Documentation/conf.py | 3 + include/linux/btf.h | 9 +++ kernel/bpf/helpers.c | 19 +++++ kernel/cgroup/rstat.c | 2 + kernel/kexec_core.c | 2 + kernel/trace/bpf_trace.c | 4 + net/bpf/test_run.c | 76 ++++++++++++------- net/ipv4/tcp_bbr.c | 8 ++ net/ipv4/tcp_cong.c | 5 ++ net/ipv4/tcp_cubic.c | 6 ++ net/ipv4/tcp_dctcp.c | 6 ++ net/netfilter/nf_conntrack_bpf.c | 14 +++- net/netfilter/nf_nat_bpf.c | 1 + net/xfrm/xfrm_interface_bpf.c | 4 +- .../selftests/bpf/bpf_testmod/bpf_testmod.c | 2 +- 16 files changed, 146 insertions(+), 33 deletions(-)
Comments
On Fri, Jan 6, 2023 at 11:51 AM David Vernet <void@manifault.com> wrote: > > BPF kfuncs are kernel functions that can be invoked by BPF programs. > kfuncs can be kernel functions which are also called elsewhere in the > main kernel (such as crash_kexec()), or may be functions that are only > meant to be used by BPF programs, such as bpf_task_acquire(), and which > are not called from anywhere else in the kernel. > > While thus far we haven't observed any issues such as kfuncs being > elided by the compiler, at some point we could easily run into problems > such as the following: > > - static kernel functions that are also used as kfuncs could be inlined > and/or elided by the compiler. > - BPF-specific kfuncs with external linkage may at some point be elided > by the compiler in LTO builds, when it's determined that they aren't > called anywhere. > > To address this, this patch set introduces a new __bpf_kfunc macro which > should be added to all kfuncs, and which will protect kfuncs from such > problems. Note that some kfuncs kind of try to do this already by > specifying noinline or __used. We are inconsistent in how this is > applied. __bpf_kfunc should provide a uniform and more-future-proof way > to do this. The series looks reasonable to me. Would be nice if we can somehow prevent (with a checkpatch?) adding new kfuncs without this new tag, but I don't see an easy way. I was waiting in case other would like to comment, but if nothing to discuss: Acked-by: Stanislav Fomichev <sdf@google.com> > David Vernet (3): > bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs > bpf: Document usage of the new __bpf_kfunc macro > bpf: Add __bpf_kfunc tag to all kfuncs > > Documentation/bpf/kfuncs.rst | 18 +++++ > Documentation/conf.py | 3 + > include/linux/btf.h | 9 +++ > kernel/bpf/helpers.c | 19 +++++ > kernel/cgroup/rstat.c | 2 + > kernel/kexec_core.c | 2 + > kernel/trace/bpf_trace.c | 4 + > net/bpf/test_run.c | 76 ++++++++++++------- > net/ipv4/tcp_bbr.c | 8 ++ > net/ipv4/tcp_cong.c | 5 ++ > net/ipv4/tcp_cubic.c | 6 ++ > net/ipv4/tcp_dctcp.c | 6 ++ > net/netfilter/nf_conntrack_bpf.c | 14 +++- > net/netfilter/nf_nat_bpf.c | 1 + > net/xfrm/xfrm_interface_bpf.c | 4 +- > .../selftests/bpf/bpf_testmod/bpf_testmod.c | 2 +- > 16 files changed, 146 insertions(+), 33 deletions(-) > > -- > 2.39.0 >
On Fri, Jan 06, 2023 at 04:47:35PM -0800, Stanislav Fomichev wrote: > On Fri, Jan 6, 2023 at 11:51 AM David Vernet <void@manifault.com> wrote: > > > > BPF kfuncs are kernel functions that can be invoked by BPF programs. > > kfuncs can be kernel functions which are also called elsewhere in the > > main kernel (such as crash_kexec()), or may be functions that are only > > meant to be used by BPF programs, such as bpf_task_acquire(), and which > > are not called from anywhere else in the kernel. > > > > While thus far we haven't observed any issues such as kfuncs being > > elided by the compiler, at some point we could easily run into problems > > such as the following: > > > > - static kernel functions that are also used as kfuncs could be inlined > > and/or elided by the compiler. > > - BPF-specific kfuncs with external linkage may at some point be elided > > by the compiler in LTO builds, when it's determined that they aren't > > called anywhere. > > > > To address this, this patch set introduces a new __bpf_kfunc macro which > > should be added to all kfuncs, and which will protect kfuncs from such > > problems. Note that some kfuncs kind of try to do this already by > > specifying noinline or __used. We are inconsistent in how this is > > applied. __bpf_kfunc should provide a uniform and more-future-proof way > > to do this. > > The series looks reasonable to me. Would be nice if we can somehow > prevent (with a checkpatch?) adding new kfuncs without this new tag, > but I don't see an easy way. > I was waiting in case other would like to comment, but if nothing to discuss: Thanks for the review, Stanislav. I agree that it would be nice to have some automation to prevent forgetting the tag. I thought about ways to possibly do it, including playing around with putting the kfuncs into a separate section for post-processing which we could check against .BTF_ids, but it felt like a lot of complexity / possibly controversial changes that I'm hesitant to bring into the patch set which should be pretty non-controversial otherwise. With respect to validating the presence of kfunc "tags" (i.e. the __diag_push() / __diag_pop() we were doing before), we're in the same state after this patch as we were before, so my preference is to defer improving that until a later time when we've fried some of the bigger kfunc fish. Does that sound ok? > Acked-by: Stanislav Fomichev <sdf@google.com> Thanks! FYI, I'm planning on sending a v2 with Alexei's suggestion [0] [0]: https://lore.kernel.org/all/CAADnVQLpK7WXTjF6GS1hcfPXf=8iERJmEeVFfvmG75mJj0DdaA@mail.gmail.com/ I'll go ahead and preemptively leave off your Acked-by for that, as the patches will have changed enough that it probably warrants another read through. - David > > > > > > David Vernet (3): > > bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs > > bpf: Document usage of the new __bpf_kfunc macro > > bpf: Add __bpf_kfunc tag to all kfuncs > > > > Documentation/bpf/kfuncs.rst | 18 +++++ > > Documentation/conf.py | 3 + > > include/linux/btf.h | 9 +++ > > kernel/bpf/helpers.c | 19 +++++ > > kernel/cgroup/rstat.c | 2 + > > kernel/kexec_core.c | 2 + > > kernel/trace/bpf_trace.c | 4 + > > net/bpf/test_run.c | 76 ++++++++++++------- > > net/ipv4/tcp_bbr.c | 8 ++ > > net/ipv4/tcp_cong.c | 5 ++ > > net/ipv4/tcp_cubic.c | 6 ++ > > net/ipv4/tcp_dctcp.c | 6 ++ > > net/netfilter/nf_conntrack_bpf.c | 14 +++- > > net/netfilter/nf_nat_bpf.c | 1 + > > net/xfrm/xfrm_interface_bpf.c | 4 +- > > .../selftests/bpf/bpf_testmod/bpf_testmod.c | 2 +- > > 16 files changed, 146 insertions(+), 33 deletions(-) > > > > -- > > 2.39.0 > >