From: daniel@iogearbox•net (Daniel Borkmann)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2] arm: eBPF JIT compiler
Date: Mon, 19 Jun 2017 20:10:50 +0200 [thread overview]
Message-ID: <594813AA.5010001@iogearbox.net> (raw)
In-Reply-To: <CAHgaXdKMbFPgy-kKF0iDSAYo4CqLn9FRu9HwM+OfM-JWb9fNRQ@mail.gmail.com>
On 06/17/2017 02:23 PM, Shubham Bansal wrote:
> Hi Daniel,
>
>> Not all of the helpers have 4 or less byte arguments only, there are a
>> few with 8 byte arguments, so making that general assumption wouldn't
>> work. I guess what could be done is that helpers have a flag in struct
>> bpf_func_proto which indicates for JITs that all args are 4 byte on 32bit
>> so you could probably use convention similar to case2 for them. Presumably
>> for that information to process, the JIT might need to be reworked to
>> extract that via bpf_analyzer() that does a verifier run to re-analyze
>> the program like in nfp JIT case.
>
> Let me try a better solution which can be used to support both 4 byte
> and 8 byte arguments. I hope it would work out. Are you sure this
> patch can pass if it only supports 4 byte arguments though?
> Let me list out what I have to do, so that you can tell me if I am
> thinking in a wrong way :-
>
> * I will add a bit flag in bpf_func_proto to represent whether
> different arguments in a function call are 4 bytes or 8 bytes. If lsb
> of bit flag is set then first argument is 8 byte, otherwise its not. I
> think I can handle this flag properly in build_insn() in my code. Does
> this sound okay?
>
> I don't understand second part of your solution, i.e.
>
>> Presumably
>> for that information to process, the JIT might need to be reworked to
>> extract that via bpf_analyzer() that does a verifier run to re-analyze
>> the program like in nfp JIT case.
>
> Please explain what are you suggesting and how can I extract bit flag
> from bpf_func_proto().
>
> Please reply asap, as I would like to finish it over the weekend. Please.
Sorry, had a travel over the weekend, so didn't read it in time.
What is the issue with imitating in JIT what the interpreter is
doing as a starting point? That should be generic enough to handle
any case.
Otherwise you'd need some sort of reverse mapping since verifier
already converted BPF_CALL insns into relative helper addresses
in imm part.
> -Shubham
>
next prev parent reply other threads:[~2017-06-19 18:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-25 23:13 [PATCH v2] arm: eBPF JIT compiler Shubham Bansal
2017-05-25 23:23 ` Andrew Lunn
2017-05-25 23:34 ` Shubham Bansal
2017-05-25 23:36 ` Shubham Bansal
2017-05-26 16:57 ` Shubham Bansal
2017-05-30 18:50 ` Shubham Bansal
2017-05-30 19:11 ` Kees Cook
[not found] ` <CAGXu5jKmLNMR+uhM9Ov2XPW6kCjip_SjScgEH0fTFp6fQtKFiA@mail.gmail.com>
[not found] ` <CAHgaXdJ=-n8J8ot_5YQC=YMZrwTBvdNTp5Ta_J_J9vNGWQ4DCQ@mail.gmail.com>
2017-06-12 2:00 ` Kees Cook
2017-06-12 10:21 ` Daniel Borkmann
2017-06-12 11:06 ` Russell King - ARM Linux
2017-06-12 15:41 ` Shubham Bansal
2017-06-12 15:40 ` Shubham Bansal
2017-06-12 22:45 ` Alexander Alemayhu
2017-06-12 22:47 ` David Miller
2017-06-12 23:17 ` Daniel Borkmann
2017-06-13 6:56 ` Shubham Bansal
2017-06-14 20:31 ` Daniel Borkmann
2017-06-17 12:23 ` Shubham Bansal
2017-06-19 18:10 ` Daniel Borkmann [this message]
2017-06-20 1:34 ` Shubham Bansal
2017-06-20 16:55 ` Daniel Borkmann
2017-06-21 14:26 ` Shubham Bansal
2017-06-21 16:32 ` Daniel Borkmann
2017-06-21 19:37 ` Shubham Bansal
2017-06-21 19:53 ` Daniel Borkmann
[not found] ` <CAHgaXdKCOM++jdoaq9PV6a_bbRU+VyuLC4KeUdYmA0gYdhmhkQ@mail.gmail.com>
2017-07-05 22:11 ` Kees Cook
2017-07-05 22:38 ` Kees Cook
[not found] ` <CAHgaXd+ywWu6PjnqGGdyw=7=XTKm4_Ny227Eq7yH5N0s0e5YfA@mail.gmail.com>
2017-07-07 4:42 ` Kees Cook
2017-07-07 4:49 ` Shubham Bansal
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=594813AA.5010001@iogearbox.net \
--to=daniel@iogearbox$(echo .)net \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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