From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Emil Tsalapatis" <emil@etsalapatis.com>, <bpf@vger.kernel.org>
Cc: <ast@kernel.org>, <andrii@kernel.org>, <eddyz87@gmail.com>,
<memxor@gmail.com>, <daniel@iogearbox.net>,
<netdev@vger.kernel.org>
Subject: Re: [PATCH bpf v2 09/11] bpf: Track whether dynptr type is known
Date: Tue, 22 Sep 2026 18:46:11 +0000 [thread overview]
Message-ID: <DLM2H0M84V64.3DRNAWAWXR4FZ@gmail.com> (raw)
In-Reply-To: <20260922172028.6269-10-emil@etsalapatis.com>
On Tue Sep 22, 2026 at 5:20 PM UTC, Emil Tsalapatis wrote:
> The TYPE_LOCAL dynptr type is used for two different
> kinds of dynptrs in the codebase: Those that are created
> locally and backed with a memory region, and those that
> are passed as arguments to a global subprog, whose type
> is not known at verification time. The two kinds require
> different handling in certain scenarios, e.g., packet
> pointer invalidation. However, there is no current way
> to distinguish them.
>
> Add a new field, type_unknown, to bpf_reg_state's dynptr-
> specific state. The field designates whether the dynptr
> type reported is accurate, or a placeholder for "type
> unknown". Adding an extra field to bpf_reg_state avoids
> unnecessarily splitting TYPE_LOCAL into two types, since
> they would behave identically in most cases.
>
> The change is currently non-functional. The new field is
> first used in the next commit.
>
> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
> ---
> include/linux/bpf_verifier.h | 2 ++
> kernel/bpf/states.c | 1 +
> kernel/bpf/verifier.c | 27 ++++++++++++++++++---------
> 3 files changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index be0ccad15..f57730d1d 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -71,6 +71,7 @@ struct bpf_reg_state {
> /* For dynptr stack slots */
> struct {
> enum bpf_dynptr_type type;
> + bool type_unknown;
why extra bool? Can it be another value in enum?
next prev parent reply other threads:[~2026-09-22 18:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 17:20 [PATCH bpf v2 00/11] skb/arena bugfixes Emil Tsalapatis
2026-09-22 17:20 ` [PATCH bpf v2 01/11] bpf: Fix bounds check for skb-backed dynptrs Emil Tsalapatis
2026-09-22 17:27 ` sashiko-bot
2026-09-22 20:15 ` Amery Hung
2026-09-22 17:20 ` [PATCH bpf v2 02/11] selftests/bpf: Test dynptr slices past end of skb Emil Tsalapatis
2026-09-22 17:28 ` sashiko-bot
2026-09-22 20:16 ` Amery Hung
2026-09-22 17:20 ` [PATCH bpf v2 03/11] bpf: Fix bpf_sock context code generation Emil Tsalapatis
2026-09-22 17:20 ` [PATCH bpf v2 04/11] selftests/bpf: Add selftests for rx_queue_mapping context access Emil Tsalapatis
2026-09-22 17:36 ` sashiko-bot
2026-09-22 17:20 ` [PATCH bpf v2 05/11] bpf: Reject pkt arguments in mutating subprogs Emil Tsalapatis
2026-09-22 20:32 ` Amery Hung
2026-09-22 17:20 ` [PATCH bpf v2 06/11] selftests/bpf: Test rejection of pkt args to " Emil Tsalapatis
2026-09-22 17:20 ` [PATCH bpf v2 07/11] bpf: Prevent variable arena/non-arena register contents Emil Tsalapatis
2026-09-22 17:20 ` [PATCH bpf v2 08/11] selftests/bpf: Test for mixed arena/nonarena code paths Emil Tsalapatis
2026-09-22 17:20 ` [PATCH bpf v2 09/11] bpf: Track whether dynptr type is known Emil Tsalapatis
2026-09-22 18:46 ` Alexei Starovoitov [this message]
2026-09-22 20:23 ` Amery Hung
2026-09-22 20:28 ` Emil Tsalapatis
2026-09-22 17:20 ` [PATCH bpf v2 10/11] bpf: Track skb memory invalidation by packet-backed dynptrs Emil Tsalapatis
2026-09-22 20:06 ` Amery Hung
2026-09-22 20:29 ` Emil Tsalapatis
2026-09-22 17:20 ` [PATCH bpf v2 11/11] selftests/bpf: Test dynptr slice invalidation on skb clobber Emil Tsalapatis
2026-09-22 19:40 ` [PATCH bpf v2 00/11] skb/arena bugfixes patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DLM2H0M84V64.3DRNAWAWXR4FZ@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.