linuxppc-dev.lists.ozlabs.org archive mirror
 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 v4 02/10] bpf: powerpc64: pad function address loads with NOPs
Date: Thu, 24 May 2018 12:26:46 +0530	[thread overview]
Message-ID: <d0db970711596827ba88209e545c686d77c22b7d.1527143877.git.sandipan@linux.vnet.ibm.com> (raw)
In-Reply-To: <cover.1527143877.git.sandipan@linux.vnet.ibm.com>
In-Reply-To: <cover.1527143877.git.sandipan@linux.vnet.ibm.com>

For multi-function programs, loading the address of a callee
function to a register requires emitting instructions whose
count varies from one to five depending on the nature of the
address.

Since we come to know of the callee's address only before the
extra pass, the number of instructions required to load this
address may vary from what was previously generated. This can
make the JITed image grow or shrink.

To avoid this, we should generate a constant five-instruction
when loading function addresses by padding the optimized load
sequence with NOPs.

Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
---
 arch/powerpc/net/bpf_jit_comp64.c | 34 +++++++++++++++++++++++-----------
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
index 1bdb1aff0619..e4582744a31d 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -167,25 +167,37 @@ static void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx)
 
 static void bpf_jit_emit_func_call(u32 *image, struct codegen_context *ctx, u64 func)
 {
+	unsigned int i, ctx_idx = ctx->idx;
+
+	/* Load function address into r12 */
+	PPC_LI64(12, func);
+
+	/* For bpf-to-bpf function calls, the callee's address is unknown
+	 * until the last extra pass. As seen above, we use PPC_LI64() to
+	 * load the callee's address, but this may optimize the number of
+	 * instructions required based on the nature of the address.
+	 *
+	 * Since we don't want the number of instructions emitted to change,
+	 * we pad the optimized PPC_LI64() call with NOPs to guarantee that
+	 * we always have a five-instruction sequence, which is the maximum
+	 * that PPC_LI64() can emit.
+	 */
+	for (i = ctx->idx - ctx_idx; i < 5; i++)
+		PPC_NOP();
+
 #ifdef PPC64_ELF_ABI_v1
-	/* func points to the function descriptor */
-	PPC_LI64(b2p[TMP_REG_2], func);
-	/* Load actual entry point from function descriptor */
-	PPC_BPF_LL(b2p[TMP_REG_1], b2p[TMP_REG_2], 0);
-	/* ... and move it to LR */
-	PPC_MTLR(b2p[TMP_REG_1]);
 	/*
 	 * Load TOC from function descriptor at offset 8.
 	 * We can clobber r2 since we get called through a
 	 * function pointer (so caller will save/restore r2)
 	 * and since we don't use a TOC ourself.
 	 */
-	PPC_BPF_LL(2, b2p[TMP_REG_2], 8);
-#else
-	/* We can clobber r12 */
-	PPC_FUNC_ADDR(12, func);
-	PPC_MTLR(12);
+	PPC_BPF_LL(2, 12, 8);
+	/* Load actual entry point from function descriptor */
+	PPC_BPF_LL(12, 12, 0);
 #endif
+
+	PPC_MTLR(12);
 	PPC_BLRL();
 }
 
-- 
2.14.3

  parent reply	other threads:[~2018-05-24  6:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-24  6:56 [PATCH bpf-next v4 00/10] bpf: enhancements for multi-function programs Sandipan Das
2018-05-24  6:56 ` [PATCH bpf-next v4 01/10] bpf: support 64-bit offsets for bpf function calls Sandipan Das
2018-05-24  6:56 ` Sandipan Das [this message]
2018-05-24  7:34   ` [PATCH bpf-next v4 02/10] bpf: powerpc64: pad function address loads with NOPs Daniel Borkmann
2018-05-24  8:25     ` Sandipan Das
2018-05-24  9:25       ` Daniel Borkmann
2018-05-24  6:56 ` [PATCH bpf-next v4 03/10] bpf: powerpc64: add JIT support for multi-function programs Sandipan Das
2018-05-24  6:56 ` [PATCH bpf-next v4 04/10] bpf: get kernel symbol addresses via syscall Sandipan Das
2018-05-24  6:56 ` [PATCH bpf-next v4 05/10] tools: bpf: sync bpf uapi header Sandipan Das
2018-05-24  6:56 ` [PATCH bpf-next v4 06/10] tools: bpftool: resolve calls without using imm field Sandipan Das
2018-05-24  6:56 ` [PATCH bpf-next v4 07/10] bpf: fix multi-function JITed dump obtained via syscall Sandipan Das
2018-05-24  6:56 ` [PATCH bpf-next v4 08/10] bpf: get JITed image lengths of functions " Sandipan Das
2018-05-24  6:56 ` [PATCH bpf-next v4 09/10] tools: bpf: sync bpf uapi header Sandipan Das
2018-05-24  6:56 ` [PATCH bpf-next v4 10/10] tools: bpftool: add delimiters to multi-function JITed dumps Sandipan Das
2018-05-24  7:04   ` Jakub Kicinski
2018-05-24  7:31 ` [PATCH bpf-next v4 00/10] bpf: enhancements for multi-function programs Daniel Borkmann

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=d0db970711596827ba88209e545c686d77c22b7d.1527143877.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).