All of lore.kernel.org
 help / color / mirror / Atom feed
From: Edward Cree <ecree@solarflare.com>
To: Jiong Wang <jiong.wang@netronome.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.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 17:29:40 +0100	[thread overview]
Message-ID: <9ed026cd-cf98-f7fc-e7d6-26117b620204@solarflare.com> (raw)
In-Reply-To: <2ff89131-c6ea-5ddf-156c-c6f6e455fbdd@netronome.com>

On 05/04/18 16:50, Jiong Wang wrote:
> 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.
<snip>
> 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
>
This is broadly similar to my medium-term plan, except that I would use
 the Kahn's-algorithm style tsort rather than the depth-first tsort
 algorithm used by current check_cfg.
* chop up prog into functions and bbs, incidentally placing S_L_Ms
* create control flow graph similar to my function call graph
* tsort it to detect loops, similar to how my check_max_stack_depth()
  implementation detects recursion.

-Ed

  reply	other threads:[~2018-04-05 16:29 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
2018-04-05 16:29     ` Edward Cree [this message]
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=9ed026cd-cf98-f7fc-e7d6-26117b620204@solarflare.com \
    --to=ecree@solarflare.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=jiong.wang@netronome.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.