All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiong Wang <jiong.wang@netronome.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Edward Cree <ecree@solarflare.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>, netdev@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications
Date: Thu, 5 Apr 2018 16:50:03 +0100	[thread overview]
Message-ID: <2ff89131-c6ea-5ddf-156c-c6f6e455fbdd@netronome.com> (raw)
In-Reply-To: <20180403010802.jkqffxw4m75oioj7@ast-mbp>

On 03/04/2018 02:08, Alexei Starovoitov wrote:
> Combining subprog pass with do_check is going into opposite direction
> of this long term work. Divide and conquer. Combining more things into
> do_check is the opposite of this programming principle.

Agree. And for the redundant insn traversal issue in check_subprogs that
Edward trying to fix, I am thinking we could do it by utilizing the
existing DFS traversal in check_cfg.

The current DFS probably could be improved into an generic instruction
information collection pass.

This won't make the existing DFS complexer as it only does information
collection as a side job during traversal. These collected information
then could be used to build any other information to be consumed later,
for example subprog, basic blocks etc.

For the redundant insn traversal issue during subprog detection, the
Like how we mark STATE_LIST_MARK in DFS, we could just call add_subprog
for BPF_PSEUDO_CALL insn during DFS.

i.e we change the code logic of check_cfg into:

check_cfg
{
   * DFS traversal:
     - detect back-edge.
     - collect STATE_LIST_MARK.
     - collect subprog destination.

   * check all insns are reachable.
   * check_subprogs (insn traversal removed).
}

I prototyped a patch for above change, the change looks to me is easier to
review. There are 8 regressions on selftests however after this change due
to check_subprogs moved after some checks in DFS that some errors detected
before the expected errors, need to be cleaned up.

Does this direction sound good?

And if we want to build basic-block later, we could just call a new add_bb
(similar as add_subprog) for jump targets etc. (some of those places are
actually STATE_LIST_MARK_JMPTARGET if we separate STATE_LIST_MARK as
STATE_LIST_MARK_JMPTARGET and STATE_LIST_MARK_HEURISTIC).

Regards,
Jiong

  parent reply	other threads:[~2018-04-05 15:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-29 22:44 [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications Edward Cree
2018-03-29 22:45 ` [PATCH v2 bpf-next 1/3] bpf/verifier: validate func_calls by marking at do_check() time Edward Cree
2018-03-29 22:46 ` [PATCH v2 bpf-next 2/3] bpf/verifier: update selftests Edward Cree
2018-03-29 22:46 ` [PATCH v2 bpf-next 3/3] bpf/verifier: per-register parent pointers Edward Cree
2018-03-29 22:50 ` [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications Edward Cree
2018-04-03  1:08 ` Alexei Starovoitov
2018-04-03 13:39   ` Edward Cree
2018-04-03 23:37     ` Alexei Starovoitov
2018-04-04 23:58       ` Edward Cree
2018-04-05  5:28         ` Alexei Starovoitov
2018-04-05  8:49           ` Edward Cree
2018-04-05 15:50   ` Jiong Wang [this message]
2018-04-05 16:29     ` Edward Cree
2018-04-06  1:20     ` Alexei Starovoitov

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=2ff89131-c6ea-5ddf-156c-c6f6e455fbdd@netronome.com \
    --to=jiong.wang@netronome.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=ecree@solarflare.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.