From: Daniel Borkmann <daniel@iogearbox.net> To: Shubham Bansal <illusionist.neo@gmail.com> Cc: Kees Cook <keescook@chromium.org>, Network Development <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>, Alexei Starovoitov <ast@kernel.org>, Russell King <linux@armlinux.org.uk>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, LKML <linux-kernel@vger.kernel.org>, Andrew Lunn <andrew@lunn.ch> Subject: Re: [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 >
WARNING: multiple messages have this Message-ID (diff)
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:11 UTC|newest] Thread overview: 87+ 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:13 ` Shubham Bansal 2017-05-25 23:23 ` Andrew Lunn 2017-05-25 23:23 ` Andrew Lunn 2017-05-25 23:34 ` Shubham Bansal 2017-05-25 23:34 ` Shubham Bansal 2017-05-25 23:36 ` Shubham Bansal 2017-05-25 23:36 ` Shubham Bansal 2017-05-26 16:57 ` Shubham Bansal 2017-05-26 16:57 ` Shubham Bansal 2017-05-30 18:50 ` Shubham Bansal 2017-05-30 18:50 ` Shubham Bansal 2017-05-30 19:11 ` Kees Cook 2017-05-30 19:11 ` Kees Cook 2017-05-30 19:19 ` Kees Cook 2017-05-30 19:19 ` Kees Cook 2017-06-06 19:47 ` Shubham Bansal 2017-06-06 19:47 ` Shubham Bansal 2017-06-12 2:00 ` Kees Cook 2017-06-12 2:00 ` Kees Cook 2017-06-12 2:00 ` Kees Cook 2017-06-12 10:21 ` Daniel Borkmann 2017-06-12 10:21 ` Daniel Borkmann 2017-06-12 10:21 ` Daniel Borkmann 2017-06-12 11:06 ` Russell King - ARM Linux 2017-06-12 11:06 ` Russell King - ARM Linux 2017-06-12 11:06 ` Russell King - ARM Linux 2017-06-12 15:41 ` Shubham Bansal 2017-06-12 15:41 ` Shubham Bansal 2017-06-12 15:41 ` Shubham Bansal 2017-06-12 15:40 ` Shubham Bansal 2017-06-12 15:40 ` Shubham Bansal 2017-06-12 15:40 ` Shubham Bansal 2017-06-12 22:45 ` Alexander Alemayhu 2017-06-12 22:45 ` Alexander Alemayhu 2017-06-12 22:45 ` Alexander Alemayhu 2017-06-12 22:47 ` David Miller 2017-06-12 22:47 ` David Miller 2017-06-12 23:17 ` Daniel Borkmann 2017-06-12 23:17 ` Daniel Borkmann 2017-06-12 23:17 ` Daniel Borkmann 2017-06-13 6:56 ` Shubham Bansal 2017-06-13 6:56 ` Shubham Bansal 2017-06-13 6:56 ` Shubham Bansal 2017-06-14 20:31 ` Daniel Borkmann 2017-06-14 20:31 ` Daniel Borkmann 2017-06-14 20:31 ` Daniel Borkmann 2017-06-17 12:23 ` Shubham Bansal 2017-06-17 12:23 ` Shubham Bansal 2017-06-17 12:23 ` Shubham Bansal 2017-06-19 18:10 ` Daniel Borkmann [this message] 2017-06-19 18:10 ` Daniel Borkmann 2017-06-19 18:10 ` Daniel Borkmann 2017-06-20 1:34 ` Shubham Bansal 2017-06-20 1:34 ` Shubham Bansal 2017-06-20 1:34 ` Shubham Bansal 2017-06-20 16:55 ` Daniel Borkmann 2017-06-20 16:55 ` Daniel Borkmann 2017-06-20 16:55 ` Daniel Borkmann 2017-06-21 14:26 ` Shubham Bansal 2017-06-21 14:26 ` Shubham Bansal 2017-06-21 14:26 ` Shubham Bansal 2017-06-21 16:32 ` Daniel Borkmann 2017-06-21 16:32 ` Daniel Borkmann 2017-06-21 16:32 ` Daniel Borkmann 2017-06-21 19:37 ` Shubham Bansal 2017-06-21 19:37 ` Shubham Bansal 2017-06-21 19:37 ` Shubham Bansal 2017-06-21 19:53 ` Daniel Borkmann 2017-06-21 19:53 ` Daniel Borkmann 2017-06-21 19:53 ` Daniel Borkmann 2017-06-23 22:39 ` Shubham Bansal 2017-06-23 22:39 ` Shubham Bansal 2017-07-05 22:11 ` Kees Cook 2017-07-05 22:11 ` Kees Cook 2017-07-05 22:11 ` Kees Cook 2017-07-05 22:38 ` Kees Cook 2017-07-05 22:38 ` Kees Cook 2017-07-05 22:38 ` Kees Cook 2017-07-06 3:49 ` Shubham Bansal 2017-07-06 3:49 ` Shubham Bansal 2017-07-07 4:42 ` Kees Cook 2017-07-07 4:42 ` Kees Cook 2017-07-07 4:42 ` Kees Cook 2017-07-07 4:49 ` Shubham Bansal 2017-07-07 4:49 ` Shubham Bansal 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.net \ --cc=andrew@lunn.ch \ --cc=ast@kernel.org \ --cc=davem@davemloft.net \ --cc=illusionist.neo@gmail.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --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: linkBe 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.