From: Shubham Bansal <illusionist.neo@gmail.com> To: Daniel Borkmann <daniel@iogearbox.net> 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: Sat, 17 Jun 2017 17:53:07 +0530 [thread overview] Message-ID: <CAHgaXdKMbFPgy-kKF0iDSAYo4CqLn9FRu9HwM+OfM-JWb9fNRQ@mail.gmail.com> (raw) In-Reply-To: <59419D1E.2060303@iogearbox.net> 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. -Shubham
WARNING: multiple messages have this Message-ID (diff)
From: illusionist.neo@gmail.com (Shubham Bansal) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2] arm: eBPF JIT compiler Date: Sat, 17 Jun 2017 17:53:07 +0530 [thread overview] Message-ID: <CAHgaXdKMbFPgy-kKF0iDSAYo4CqLn9FRu9HwM+OfM-JWb9fNRQ@mail.gmail.com> (raw) In-Reply-To: <59419D1E.2060303@iogearbox.net> 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. -Shubham
next prev parent reply other threads:[~2017-06-17 12:23 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 [this message] 2017-06-17 12:23 ` Shubham Bansal 2017-06-17 12:23 ` Shubham Bansal 2017-06-19 18:10 ` Daniel Borkmann 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=CAHgaXdKMbFPgy-kKF0iDSAYo4CqLn9FRu9HwM+OfM-JWb9fNRQ@mail.gmail.com \ --to=illusionist.neo@gmail.com \ --cc=andrew@lunn.ch \ --cc=ast@kernel.org \ --cc=daniel@iogearbox.net \ --cc=davem@davemloft.net \ --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.