From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Subject: Re: [PATCH net] bpf, arm: start flushing icache range from header Date: Mon, 16 Nov 2015 11:40:55 +0000 Message-ID: <20151116114055.GC20696@leverpostej> References: <971980449d680e6b26e273130d74546c5148893c.1447446440.git.daniel@iogearbox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: davem@davemloft.net, linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org, ast@kernel.org, nschichan@freebox.fr To: Daniel Borkmann Return-path: Received: from foss.arm.com ([217.140.101.70]:48650 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751728AbbKPLlB (ORCPT ); Mon, 16 Nov 2015 06:41:01 -0500 Content-Disposition: inline In-Reply-To: <971980449d680e6b26e273130d74546c5148893c.1447446440.git.daniel@iogearbox.net> Sender: netdev-owner@vger.kernel.org List-ID: On Sat, Nov 14, 2015 at 01:26:53AM +0100, Daniel Borkmann wrote: > During review I noticed that the icache range we're flushing should > start at header already and not at ctx.image. > > Reason is that after 55309dd3d4cd ("net: bpf: arm: address randomize > and write protect JIT code"), we also want to make sure to flush the > random-sized trap in front of the start of the actual program (analogous > to x86). No operational differences from user side. > > Signed-off-by: Daniel Borkmann > Tested-by: Nicolas Schichan > Cc: Alexei Starovoitov > --- > ( As arm32 fixes usually go via Dave's tree, targeting -net. ) > > arch/arm/net/bpf_jit_32.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c > index 2f4b14c..591f9db 100644 > --- a/arch/arm/net/bpf_jit_32.c > +++ b/arch/arm/net/bpf_jit_32.c > @@ -1061,7 +1061,7 @@ void bpf_jit_compile(struct bpf_prog *fp) > } > build_epilogue(&ctx); > > - flush_icache_range((u32)ctx.target, (u32)(ctx.target + ctx.idx)); > + flush_icache_range((u32)header, (u32)(ctx.target + ctx.idx)); As with the arm64 patch, doesn't this prevent us from flushing the end of the image? ctx.idx doesn't seem to take into account the header size. Mark.