From patchwork Wed Jan 25 14:38:16 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Vernet X-Patchwork-Id: 48172 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp308657wrn; Wed, 25 Jan 2023 06:40:37 -0800 (PST) X-Google-Smtp-Source: AMrXdXt60bMPvjdlRSosCoHFWin3IufxFxAL5y35AWmPnT/DI8kK1eE48AtMPLSyQGw/GnHvKPDj X-Received: by 2002:a05:6a20:a698:b0:b8:4fcc:ff74 with SMTP id ba24-20020a056a20a69800b000b84fccff74mr37230264pzb.17.1674657636884; Wed, 25 Jan 2023 06:40:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674657636; cv=none; d=google.com; s=arc-20160816; b=mAanpp5Jby5HonG1YCQJ3BYCffAafg1idfEK3Hq44g6SRtmUV6HHhXNTN6zBdt8nX7 v7EIdypmym3syriQMLZqOILMTL+j7vfKh4HCBEKUuPNhbxAgxyH4duZ8qj/IF+qA1y3D rtNFwy3Nalm5O44/C5MpIjjh1Z+l0N6lWvC8UnZbmjEiWYFhpg4NyHgGna4wYl5i1t+K icgzo2RBwFpMbELvJSH+yI2g7vcJ4JxewQSeDB8I54rfth9ib33X29f4IqsJHdIccd10 OsYajkjxpcAv8jARjpB6Ct86MH33g3EzujiQEWlASkdt0y0di40llKXgt0r5Qq/WV3CS y1Lw== 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=ovlVrIKnsLO1876JlAbege0XF/0rg73ghXA+lp23XMs=; b=fWDeM/LcjpLjf1CEqd3c0cKGBSfZkUiz79xaT9sRvRBOHPuXZlINH3aLfEXx5SMkYO CAM/Ga94Kv94he0FfMuwunsr5PbpgItmPQJ05rJMNGjINpJGj+1LN3A1RbMmKf/1+dfl PGP6ADWCDuNKgxK/Os8skow5KUdmJiJH91TTE7mNK+Gly/xb9sAmAoN+brSUuIvPl56X BQxVZFzvSpHZvmzZqlS2tBPGxA/asqMYIJlSJQshG/m0U2XnTCDoiXG3PtEZmt6lWwPf iPgUtIFIloHUN682YZYErTKFtrEz0Tbqa0M5zABwLvSeScjMAXfxCDyK2w9u67/mVB8W INqg== 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 f26-20020a639c1a000000b00478fd997431si5223694pge.872.2023.01.25.06.40.24; Wed, 25 Jan 2023 06:40:36 -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 S235817AbjAYOkK (ORCPT + 99 others); Wed, 25 Jan 2023 09:40:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235780AbjAYOkD (ORCPT ); Wed, 25 Jan 2023 09:40:03 -0500 Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67AA9BB80; Wed, 25 Jan 2023 06:39:34 -0800 (PST) Received: by mail-vs1-f53.google.com with SMTP id i185so19960175vsc.6; Wed, 25 Jan 2023 06:39:34 -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=ovlVrIKnsLO1876JlAbege0XF/0rg73ghXA+lp23XMs=; b=z1mNs0HB2mIHtxs0MMHIKaQz5CXxDthfCzijQEpiiXjdrBTuCmka0jV/HpMgWbPWDo a6pEveyG/croMndhXo9AGYGrgzJ63mdDG1K5a3fiaiYBw3UdNZm/jTDVVj+bjMDcFlLm G8rcnFa+l/Ac2BCu/L0C+++suC2WvkjuyiUrEmTkU+RK3+2GSBBpqRvRj0o2g8LjCamB vZtFMZbLIVkxBA9B4pWNWTzYstLhun0CMmpsnt0A/A3/kzviaM8k+4h9YVmLksjubElc K2R9lDuS1cxKVpaay/9Gw8UCZCgsWadTXT8I52evlcmI2PzU1XDACy0DEcUgvZCic0s3 5itw== X-Gm-Message-State: AO0yUKXQPdt67Y8XHBLuJDwE1RBwgnPcYl0Lt5oHPAAHdK2cY1Giww04 pznNzx6OruPrtn3aybQO4OG3LmexOsXx/SyZ X-Received: by 2002:a05:6102:161f:b0:3e8:9a3c:f2fa with SMTP id cu31-20020a056102161f00b003e89a3cf2famr2082416vsb.4.1674657509185; Wed, 25 Jan 2023 06:38:29 -0800 (PST) Received: from localhost ([24.1.27.177]) by smtp.gmail.com with ESMTPSA id os37-20020a05620a812500b0070650f5ee2fsm3572473qkn.65.2023.01.25.06.38.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Jan 2023 06:38:28 -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, tj@kernel.org, memxor@gmail.com Subject: [PATCH bpf-next v3 7/7] bpf/docs: Document the nocast aliasing behavior of ___init Date: Wed, 25 Jan 2023 08:38:16 -0600 Message-Id: <20230125143816.721952-8-void@manifault.com> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20230125143816.721952-1-void@manifault.com> References: <20230125143816.721952-1-void@manifault.com> MIME-Version: 1.0 X-Spam-Status: No, score=-1.6 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?1756005806491817430?= X-GMAIL-MSGID: =?utf-8?q?1756005806491817430?= When comparing BTF IDs for pointers being passed to kfunc arguments, the verifier will allow pointer types that are equivalent according to the C standard. For example, for: struct bpf_cpumask { cpumask_t cpumask; refcount_t usage; }; The verifier will allow a struct bpf_cpumask * to be passed to a kfunc that takes a const struct cpumask * (cpumask_t is a typedef of struct cpumask). The exception to this rule is if a type is suffixed with ___init, such as: struct nf_conn___init { struct nf_conn ct; }; The verifier will _not_ allow a struct nf_conn___init * to be passed to a kfunc that expects a struct nf_conn *. This patch documents this behavior in the kfuncs documentation page. Signed-off-by: David Vernet --- Documentation/bpf/kfuncs.rst | 43 ++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst index 560f4ede3a9f..1a683225d080 100644 --- a/Documentation/bpf/kfuncs.rst +++ b/Documentation/bpf/kfuncs.rst @@ -247,6 +247,49 @@ type. An example is shown below:: } late_initcall(init_subsystem); +2.6 Specifying no-cast aliases with ___init +-------------------------------------------- + +The verifier will always enforce that the BTF type of a pointer passed to a +kfunc by a BPF program, matches the type of pointer specified in the kfunc +definition. The verifier, does, however, allow types that are equivalent +according to the C standard to be passed to the same kfunc arg, even if their +BTF_IDs differ. + +For example, for the following type definition: + +.. code-block:: c + + struct bpf_cpumask { + cpumask_t cpumask; + refcount_t usage; + }; + +The verifier would allow a ``struct bpf_cpumask *`` to be passed to a kfunc +taking a ``cpumask_t *`` (which is a typedef of ``struct cpumask *``). For +instance, both ``struct cpumask *`` and ``struct bpf_cpmuask *`` can be passed +to bpf_cpumask_test_cpu(). + +In some cases, this type-aliasing behavior is not desired. ``struct +nf_conn___init`` is one such example: + +.. code-block:: c + + struct nf_conn___init { + struct nf_conn ct; + }; + +The C standard would consider these types to be equivalent, but it would not +always be safe to pass either type to a trusted kfunc. ``struct +nf_conn___init`` represents an allocated ``struct nf_conn`` object that has +*not yet been initialized*, so it would therefore be unsafe to pass a ``struct +nf_conn___init *`` to a kfunc that's expecting a fully initialized ``struct +nf_conn *`` (e.g. ``bpf_ct_change_timeout()``). + +In order to accommodate such requirements, the verifier will enforce strict +PTR_TO_BTF_ID type matching if two types have the exact same name, with one +being suffixed with ``___init``. + 3. Core kfuncs ==============