All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.