Thread (21 messages) 21 messages, 4 authors, 5d ago

Re: [PATCH bpf v2 09/11] bpf: Track whether dynptr type is known

From: "Emil Tsalapatis" <emil@etsalapatis.com>
Date: 2026-09-22 20:28:21
Also in: bpf

On Tue Sep 22, 2026 at 8:23 PM UTC, Amery Hung wrote:
On Tue, Sep 22, 2026 at 11:49 AM Alexei Starovoitov
[off-list ref] wrote:
quoted
On Tue Sep 22, 2026 at 5:20 PM UTC, Emil Tsalapatis wrote:
quoted
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?
Second this. Could be a BPF_DYNPTR_TYPE_UNKNOWN or BPF_DYNPTR_TYPE_ANY.
Sounds good, let's go with that. The reasoning behind the extra bool was to
avoid having to add TYPE_UNKNOWN everywhere as an extra case statement, because
the two enums would have identical behavior except for the check added in the
next patch.
quoted
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help