From: Pete Heist <pete@heistp.net>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Dave Taht <dave.taht@gmail.com>, Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] [bpf-next RFC 2/3] flow_dissector: implements eBPF parser
Date: Wed, 22 Aug 2018 11:37:13 +0200 [thread overview]
Message-ID: <CF65E607-5E6B-403C-B4A1-83B166043E7E@heistp.net> (raw)
In-Reply-To: <871saqah2m.fsf@toke.dk>
> On Aug 22, 2018, at 11:25 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Pete Heist <pete@heistp.net> writes:
>
>> The eBPF verifier seems fragile to me, where I’d be moving lines of
>> code around and getting different error messages in an alien tongue.
>
> Well, it operates on the byte code and errs on the side of safety. I.e.,
> if it can't prove your program is safe it is going to reject it. Which
> can be less than helpful.
Yes, understood. I just found it sensitive to the place where variables are initialized, for example, even when the code looked equivalent. I’ll present a concrete example to them when I see it again.
> There's a mode where it can dump its state including the byte code it is
> operating at, which can be helpful in figuring out why you get an error.
> But it has a way to go yet compared with regular compiler error
> messages... :)
Yes, as examples: "R2 type=inv expected=fp” (which I think means that a value should was expected to be on the stack but was not) or "math between pkt pointer and 4294901760 is not allowed”, might not suggest what one needs to do, although there are hints available if one searches… :)
next prev parent reply other threads:[~2018-08-22 9:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180816164423.14368-1-peterpenkov96@gmail.com>
[not found] ` <20180816164423.14368-3-peterpenkov96@gmail.com>
2018-08-18 17:19 ` [Cake] Fwd: " Dave Taht
2018-08-22 9:16 ` [Cake] " Pete Heist
2018-08-22 9:25 ` Toke Høiland-Jørgensen
2018-08-22 9:37 ` Pete Heist [this message]
2018-08-22 10:41 ` Daniel Borkmann
2018-08-22 16:50 ` Dave Taht
2018-08-22 19:18 ` Pete Heist
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
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CF65E607-5E6B-403C-B4A1-83B166043E7E@heistp.net \
--to=pete@heistp.net \
--cc=cake@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=toke@toke.dk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox