All of lore.kernel.org
 help / color / mirror / Atom feed
From: Seunghyeon Lee <hyeon3125@gmail.com>
To: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>, bpf@vger.kernel.org
Subject: Re: [PATCH RFC] bpf: add DAG fast-path in verifier to skip redundant state pruning
Date: Sat, 30 May 2026 02:12:52 +0000	[thread overview]
Message-ID: <178010717294.19003.10323978025488327836@gmail.com> (raw)
In-Reply-To: <DIVM9YXYJV5N.2TEM951JWKD95@gmail.com>

Alexei,

Agreed — DAG-only is the narrow case. The general case is the right direction.

On merge_verifier_state():
I've been looking at this from two angles:

Transfer-function approach (your direction): merge_verifier_state() as
the join operator in a dataflow lattice. The key question: what's the
minimal state representation that preserves safety without full state
enumeration?

Proof-carrying approach (longer-term): If a compiler can prove properties
about the transfer function before loading, the verifier only needs to
check the proof, not simulate the lattice. This is essentially PCC
(Necula 1997) applied to BPF.

These two converge at merge_verifier_state(): the join operator defines
the abstract domain. If the domain is finite and the transfer functions
are monotone, you get termination for free — proof becomes a byproduct.

Looking forward to seeing your prototype. What representation are you
using for the abstract state?

- Seunghyeon

  reply	other threads:[~2026-05-30  2:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-29  8:38 [PATCH RFC] bpf: add DAG fast-path in verifier to skip redundant state pruning Seunghyeon Lee
2026-05-30  1:23 ` Alexei Starovoitov
2026-05-30  2:12   ` Seunghyeon Lee [this message]
2026-06-24 17:38   ` L0

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=178010717294.19003.10323978025488327836@gmail.com \
    --to=hyeon3125@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    /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.