All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sandipan Das <sandipan@linux.vnet.ibm.com>
To: ast@kernel.org, daniel@iogearbox.net
Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	mpe@ellerman.id.au, naveen.n.rao@linux.vnet.ibm.com,
	jakub.kicinski@netronome.com
Subject: [PATCH bpf-next v3 01/10] bpf: support 64-bit offsets for bpf function calls
Date: Tue, 22 May 2018 22:46:04 +0530	[thread overview]
Message-ID: <6d0a491b74c233af3299282dd8763d09a6c6c8cd.1527008646.git.sandipan@linux.vnet.ibm.com> (raw)
In-Reply-To: <cover.1527008646.git.sandipan@linux.vnet.ibm.com>
In-Reply-To: <cover.1527008646.git.sandipan@linux.vnet.ibm.com>

The imm field of a bpf instruction is a signed 32-bit integer.
For JITed bpf-to-bpf function calls, it holds the offset of the
start address of the callee's JITed image from __bpf_call_base.

For some architectures, such as powerpc64, this offset may be
as large as 64 bits and cannot be accomodated in the imm field
without truncation.

We resolve this by:

[1] Additionally using the auxillary data of each function to
    keep a list of start addresses of the JITed images for all
    functions determined by the verifier.

[2] Retaining the subprog id inside the off field of the call
    instructions and using it to index into the list mentioned
    above and lookup the callee's address.

To make sure that the existing JIT compilers continue to work
without requiring changes, we keep the imm field as it is.

Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
---
 kernel/bpf/verifier.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index a9e4b1372da6..559cb74ba29e 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5383,11 +5383,24 @@ static int jit_subprogs(struct bpf_verifier_env *env)
 			    insn->src_reg != BPF_PSEUDO_CALL)
 				continue;
 			subprog = insn->off;
-			insn->off = 0;
 			insn->imm = (u64 (*)(u64, u64, u64, u64, u64))
 				func[subprog]->bpf_func -
 				__bpf_call_base;
 		}
+
+		/* we use the aux data to keep a list of the start addresses
+		 * of the JITed images for each function in the program
+		 *
+		 * for some architectures, such as powerpc64, the imm field
+		 * might not be large enough to hold the offset of the start
+		 * address of the callee's JITed image from __bpf_call_base
+		 *
+		 * in such cases, we can lookup the start address of a callee
+		 * by using its subprog id, available from the off field of
+		 * the call instruction, as an index for this list
+		 */
+		func[i]->aux->func = func;
+		func[i]->aux->func_cnt = env->subprog_cnt;
 	}
 	for (i = 0; i < env->subprog_cnt; i++) {
 		old_bpf_func = func[i]->bpf_func;
-- 
2.14.3

  reply	other threads:[~2018-05-22 17:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-22 17:16 [PATCH bpf-next v3 00/10] bpf: enhancements for multi-function programs Sandipan Das
2018-05-22 17:16 ` Sandipan Das [this message]
2018-05-22 17:16 ` [PATCH bpf-next v3 02/10] bpf: powerpc64: pad function address loads with NOPs Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 03/10] bpf: powerpc64: add JIT support for multi-function programs Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 04/10] bpf: get kernel symbol addresses via syscall Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 05/10] tools: bpf: sync bpf uapi header Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 06/10] tools: bpftool: resolve calls without using imm field Sandipan Das
2018-05-22 19:36   ` Jakub Kicinski
2018-05-22 17:16 ` [PATCH bpf-next v3 07/10] bpf: fix multi-function JITed dump obtained via syscall Sandipan Das
2018-05-22 19:47   ` Jakub Kicinski
2018-05-22 17:16 ` [PATCH bpf-next v3 08/10] bpf: get JITed image lengths of functions " Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 09/10] tools: bpf: sync bpf uapi header Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 10/10] tools: bpftool: add delimiters to multi-function JITed dumps Sandipan Das
2018-05-22 19:55   ` Jakub Kicinski
2018-05-23  9:08     ` Daniel Borkmann
2018-05-23 10:37       ` Sandipan Das
2018-05-23 13:50         ` Daniel Borkmann
2018-05-23 13:59           ` Sandipan Das
2018-05-23 21:32         ` Jakub Kicinski

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=6d0a491b74c233af3299282dd8763d09a6c6c8cd.1527008646.git.sandipan@linux.vnet.ibm.com \
    --to=sandipan@linux.vnet.ibm.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --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.