Hi Will,
On Mon, Jun 6, 2016 at 10:05 AM, Will Deacon wrote:
> On Sat, Jun 04, 2016 at 03:00:29PM -0700, Zi Shen Lim wrote:
>> Remove superfluous stack frame, saving us 3 instructions for
>> every JMP_CALL.
>>
>> Signed-off-by: Zi Shen Lim
>> ---
>>
Hi Will,
On Mon, Jun 6, 2016 at 10:05 AM, Will Deacon wrote:
> On Sat, Jun 04, 2016 at 03:00:29PM -0700, Zi Shen Lim wrote:
>> Remove superfluous stack frame, saving us 3 instructions for
>> every JMP_CALL.
>>
>> Signed-off-by: Zi Shen Lim
>> ---
>> arch/arm64/net/bpf_jit_comp.c | 3 ---
>> 1
Hi Daniel,
On Sun, Jun 5, 2016 at 12:53 AM, Daniel Borkmann wrote:
> On 06/05/2016 01:46 AM, kbuild test robot wrote:
>>
>> Hi,
>>
>> [auto build test ERROR on net-next/master]
>>
>> url:
>>
Hi Daniel,
On Sun, Jun 5, 2016 at 12:53 AM, Daniel Borkmann wrote:
> On 06/05/2016 01:46 AM, kbuild test robot wrote:
>>
>> Hi,
>>
>> [auto build test ERROR on net-next/master]
>>
>> url:
>>
Hi Yang,
On Mon, May 16, 2016 at 4:09 PM, Yang Shi wrote:
> In the current implementation of ARM64 eBPF JIT, R23 and R24 are used for
> tmp registers, which are callee-saved registers. This leads to variable size
> of JIT prologue and epilogue. The latest blinding constant
Hi Yang,
On Mon, May 16, 2016 at 4:09 PM, Yang Shi wrote:
> In the current implementation of ARM64 eBPF JIT, R23 and R24 are used for
> tmp registers, which are callee-saved registers. This leads to variable size
> of JIT prologue and epilogue. The latest blinding constant change prefers to
>
On Wed, Nov 18, 2015 at 1:07 PM, Shi, Yang wrote:
> On 11/18/2015 12:56 AM, Zi Shen Lim wrote:
>> emit_a64_mov_i64(r3, size, ctx);
>> - emit(A64_ADD_I(1, r4, fp, MAX_BPF_STACK), ctx);
>> + emit(A64_SUB_I(1, r4, fp, STACK_SIZE), ctx);
>
>
> Should not it
On Wed, Nov 18, 2015 at 1:07 PM, Shi, Yang wrote:
> On 11/18/2015 12:56 AM, Zi Shen Lim wrote:
>> emit_a64_mov_i64(r3, size, ctx);
>> - emit(A64_ADD_I(1, r4, fp, MAX_BPF_STACK), ctx);
>> + emit(A64_SUB_I(1, r4, fp, STACK_SIZE),
On Mon, Nov 16, 2015 at 2:35 PM, Yang Shi wrote:
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
> change during function call so it
On Mon, Nov 16, 2015 at 2:35 PM, Yang Shi wrote:
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
> change during
Yang, I noticed another thing...
On Fri, Nov 13, 2015 at 10:09 AM, Yang Shi wrote:
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
>
Yang, I noticed another thing...
On Fri, Nov 13, 2015 at 10:09 AM, Yang Shi wrote:
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register,
On Thu, Nov 12, 2015 at 11:33 AM, Shi, Yang wrote:
> On 11/11/2015 4:39 AM, Will Deacon wrote:
>>
>> Wait a second, we're both talking rubbish here :) The STR (immediate)
>> form is referring to the addressing mode, whereas this patch wants to
>> store an immediate value to memory, which does
On Thu, Nov 12, 2015 at 1:57 PM, Yang Shi wrote:
>
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
> change during function call so it
On Thu, Nov 12, 2015 at 1:57 PM, Yang Shi wrote:
> BPF fp should point to the top of the BPF prog stack. The original
> implementation made it point to the bottom incorrectly.
> Move A64_SP to fp before reserve BPF prog stack space.
>
> CC: Zi Shen Lim
> CC: Xi Wang
> Signed-off-by: Yang Shi
>
On Thu, Nov 12, 2015 at 1:57 PM, Yang Shi wrote:
>
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
> change during
On Thu, Nov 12, 2015 at 1:57 PM, Yang Shi wrote:
> BPF fp should point to the top of the BPF prog stack. The original
> implementation made it point to the bottom incorrectly.
> Move A64_SP to fp before reserve BPF prog stack space.
>
> CC: Zi Shen Lim
>
On Thu, Nov 12, 2015 at 11:33 AM, Shi, Yang wrote:
> On 11/11/2015 4:39 AM, Will Deacon wrote:
>>
>> Wait a second, we're both talking rubbish here :) The STR (immediate)
>> form is referring to the addressing mode, whereas this patch wants to
>> store an immediate value to
On Tue, Nov 10, 2015 at 11:46 AM, Shi, Yang wrote:
> On 11/9/2015 12:00 PM, Z Lim wrote:
>>
>> How about splitting this into two patches? One for the BPF-related
>> bug, and another for A64 FP-handling.
>
> I'm not sure if this is a good approach or not. IMHO, they ar
Yang,
On Tue, Nov 10, 2015 at 4:42 PM, Alexei Starovoitov
wrote:
> On Tue, Nov 10, 2015 at 04:26:02PM -0800, Shi, Yang wrote:
>> On 11/10/2015 4:08 PM, Eric Dumazet wrote:
>> >On Tue, 2015-11-10 at 14:41 -0800, Yang Shi wrote:
>> >>aarch64 doesn't have native support for XADD instruction,
On Tue, Nov 10, 2015 at 2:41 PM, Yang Shi wrote:
> aarch64 doesn't have native store immediate instruction, such operation
Actually, aarch64 does have "STR (immediate)". For arm64 JIT, we can
consider using it as an optimization.
You may also want to consider adding a note about the
On Tue, Nov 10, 2015 at 2:41 PM, Yang Shi wrote:
> aarch64 doesn't have native store immediate instruction, such operation
Actually, aarch64 does have "STR (immediate)". For arm64 JIT, we can
consider using it as an optimization.
You may also want to consider adding a note
Yang,
On Tue, Nov 10, 2015 at 4:42 PM, Alexei Starovoitov
wrote:
> On Tue, Nov 10, 2015 at 04:26:02PM -0800, Shi, Yang wrote:
>> On 11/10/2015 4:08 PM, Eric Dumazet wrote:
>> >On Tue, 2015-11-10 at 14:41 -0800, Yang Shi wrote:
>> >>aarch64 doesn't have native
On Tue, Nov 10, 2015 at 11:46 AM, Shi, Yang <yang@linaro.org> wrote:
> On 11/9/2015 12:00 PM, Z Lim wrote:
>>
>> How about splitting this into two patches? One for the BPF-related
>> bug, and another for A64 FP-handling.
>
> I'm not sure if this is a good app
On Mon, Nov 9, 2015 at 10:08 AM, Shi, Yang wrote:
> I added it to stay align with ARMv8 AAPCS to maintain the correct FP during
> function call. It makes us get correct stack backtrace.
>
> I think we'd better to keep compliant with ARMv8 AAPCS in BPF JIT prologue
> too.
>
> If nobody thinks it
On Mon, Nov 9, 2015 at 10:08 AM, Shi, Yang wrote:
> I added it to stay align with ARMv8 AAPCS to maintain the correct FP during
> function call. It makes us get correct stack backtrace.
>
> I think we'd better to keep compliant with ARMv8 AAPCS in BPF JIT prologue
> too.
>
>
On Sat, Nov 7, 2015 at 6:27 PM, Alexei Starovoitov
wrote:
> On Fri, Nov 06, 2015 at 09:36:17PM -0800, Yang Shi wrote:
>> ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to
>> change during function call so it may cause the BPF prog stack base address
>> change too. Whenever, it
On Sat, Nov 7, 2015 at 6:27 PM, Alexei Starovoitov
wrote:
> On Fri, Nov 06, 2015 at 09:36:17PM -0800, Yang Shi wrote:
>> ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to
>> change during function call so it may cause the BPF prog stack base address
On Wed, Nov 4, 2015 at 11:36 AM, Yang Shi wrote:
> When running "mod X" operation, if X is 0 the filter has to be halt.
> Add new test cases to cover A = A mod X if X is 0, and A = A mod 1.
>
> CC: Xi Wang
> CC: Zi Shen Lim
> Signed-off-by: Yang Shi
> ---
Acked-by: Zi Shen Lim
--
To
On Wed, Nov 4, 2015 at 10:21 AM, Shi, Yang wrote:
> On 11/3/2015 11:04 PM, Xi Wang wrote:
>>
>> On Tue, Nov 3, 2015 at 10:56 PM, Zi Shen Lim wrote:
>>>
>>> case BPF_ALU | BPF_DIV | BPF_X:
>>> case BPF_ALU64 | BPF_DIV | BPF_X:
>>> + {
>>> + const u8 r0 =
On Wed, Nov 4, 2015 at 11:36 AM, Yang Shi wrote:
> When running "mod X" operation, if X is 0 the filter has to be halt.
> Add new test cases to cover A = A mod X if X is 0, and A = A mod 1.
>
> CC: Xi Wang
> CC: Zi Shen Lim
>
On Wed, Nov 4, 2015 at 10:21 AM, Shi, Yang wrote:
> On 11/3/2015 11:04 PM, Xi Wang wrote:
>>
>> On Tue, Nov 3, 2015 at 10:56 PM, Zi Shen Lim wrote:
>>>
>>> case BPF_ALU | BPF_DIV | BPF_X:
>>> case BPF_ALU64 | BPF_DIV | BPF_X:
>>> +
Hi Alexei,
On Sat, Nov 29, 2014 at 2:46 PM, Alexei Starovoitov wrote:
> classic BPF has a restriction that last insn is always BPF_RET.
> eBPF doesn't have BPF_RET instruction and this restriction.
> It has BPF_EXIT insn which can appear anywhere in the program
> one or more times and it doesn't
Hi Alexei,
On Sat, Nov 29, 2014 at 2:46 PM, Alexei Starovoitov a...@plumgrid.com wrote:
classic BPF has a restriction that last insn is always BPF_RET.
eBPF doesn't have BPF_RET instruction and this restriction.
It has BPF_EXIT insn which can appear anywhere in the program
one or more times
Hi Andre,
On Thu, Oct 23, 2014 at 10:00 AM, Andre Przywara wrote:
> Hi,
>
> I see a crash with 3.18-rc1 on a Juno board related to bpf_jit (see dump
> below). Userland tries to carry on afterwards, but eventually hangs in
> RCU stalls.
> The kernel has just CONFIG_BPF_JIT enabled, I guess Ubuntu
Hi Andre,
On Thu, Oct 23, 2014 at 10:00 AM, Andre Przywara andre.przyw...@arm.com wrote:
Hi,
I see a crash with 3.18-rc1 on a Juno board related to bpf_jit (see dump
below). Userland tries to carry on afterwards, but eventually hangs in
RCU stalls.
The kernel has just CONFIG_BPF_JIT
Hi Catalin, Will,
On Tue, Sep 16, 2014 at 12:48 AM, Daniel Borkmann wrote:
[...]
> +static void jit_fill_hole(void *area, unsigned int size)
> +{
> + u32 *ptr;
> + /* We are guaranteed to have aligned memory. */
> + for (ptr = area; size >= sizeof(u32); size -= sizeof(u32))
> +
On Tue, Sep 16, 2014 at 9:25 AM, Will Deacon wrote:
> On Tue, Sep 16, 2014 at 08:48:50AM +0100, Daniel Borkmann wrote:
>> This is the ARM64 variant for 314beb9bcab ("x86: bpf_jit_comp: secure bpf
>> jit against spraying attacks").
>>
>> Thanks to commit 11d91a770f1f ("arm64: Add
On Tue, Sep 16, 2014 at 9:25 AM, Will Deacon will.dea...@arm.com wrote:
On Tue, Sep 16, 2014 at 08:48:50AM +0100, Daniel Borkmann wrote:
This is the ARM64 variant for 314beb9bcab (x86: bpf_jit_comp: secure bpf
jit against spraying attacks).
Thanks to commit 11d91a770f1f (arm64: Add
Hi Catalin, Will,
On Tue, Sep 16, 2014 at 12:48 AM, Daniel Borkmann dbork...@redhat.com wrote:
[...]
+static void jit_fill_hole(void *area, unsigned int size)
+{
+ u32 *ptr;
+ /* We are guaranteed to have aligned memory. */
+ for (ptr = area; size = sizeof(u32); size -=
On Fri, Sep 12, 2014 at 10:35 AM, Daniel Borkmann wrote:
> This is the ARM64 variant for 314beb9bcab ("x86: bpf_jit_comp: secure bpf
> jit against spraying attacks").
>
> Thanks to commit 11d91a770f1f ("arm64: Add CONFIG_DEBUG_SET_MODULE_RONX
> support") which added necessary infrastructure, we
On Fri, Sep 12, 2014 at 10:35 AM, Daniel Borkmann dbork...@redhat.com wrote:
This is the ARM64 variant for 314beb9bcab (x86: bpf_jit_comp: secure bpf
jit against spraying attacks).
Thanks to commit 11d91a770f1f (arm64: Add CONFIG_DEBUG_SET_MODULE_RONX
support) which added necessary
On Thu, Sep 11, 2014 at 3:45 AM, Will Deacon wrote:
> On Thu, Sep 11, 2014 at 10:36:48AM +0100, Daniel Borkmann wrote:
>> On ARM64, when the BPF JIT compiler fills the JIT image body with
>> opcodes during translation of eBPF into ARM64 opcodes, we may fail
>> for several reasons during that
On Thu, Sep 11, 2014 at 3:45 AM, Will Deacon will.dea...@arm.com wrote:
On Thu, Sep 11, 2014 at 10:36:48AM +0100, Daniel Borkmann wrote:
On ARM64, when the BPF JIT compiler fills the JIT image body with
opcodes during translation of eBPF into ARM64 opcodes, we may fail
for several reasons
Hi Will,
On Tue, Aug 26, 2014 at 2:58 AM, Will Deacon wrote:
> Hi Z Lim,
>
> On Thu, Jul 24, 2014 at 05:55:36AM +0100, Z Lim wrote:
>> On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
>> wrote:
>> > On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wro
Hi Will,
On Tue, Aug 26, 2014 at 2:58 AM, Will Deacon will.dea...@arm.com wrote:
Hi Z Lim,
On Thu, Jul 24, 2014 at 05:55:36AM +0100, Z Lim wrote:
On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov
On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
wrote:
> On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote:
>> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon wrote:
>> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
[...]
>> >> This series applies against net-next
On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote:
On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon will.dea...@arm.com wrote:
On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
[...]
This
On Mon, Jul 21, 2014 at 8:49 AM, Alexei Starovoitov wrote:
> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon wrote:
[...]
>>> This series applies against net-next and is tested working
>>> with lib/test_bpf on ARMv8 Foundation Model.
>>
>> Looks like it works on my Juno board too, so:
>>
>>
On Mon, Jul 21, 2014 at 8:49 AM, Alexei Starovoitov a...@plumgrid.com wrote:
On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon will.dea...@arm.com wrote:
[...]
This series applies against net-next and is tested working
with lib/test_bpf on ARMv8 Foundation Model.
Looks like it works on my Juno
(resending this email in case the first one got caught in your spam
filter. sorry.)
On Thu, Jul 17, 2014 at 10:41:02AM +0100, Will Deacon wrote:
> On Wed, Jul 16, 2014 at 11:04:22PM +0100, Zi Shen Lim wrote:
> > On Wed, Jul 16, 2014 at 05:17:15PM +0100, Will Deacon wrote:
> > > On Tue, Jul 15,
(resending this email in case the first one got caught in your spam
filter. sorry.)
On Thu, Jul 17, 2014 at 06:25:26PM +0100, Will Deacon wrote:
> On Thu, Jul 17, 2014 at 04:59:10PM +0100, Alexei Starovoitov wrote:
> > On Thu, Jul 17, 2014 at 2:19 AM, Will Deacon wrote:
> > > On Wed, Jul 16,
(resending this email in case the first one got caught in your spam
filter. sorry.)
On Thu, Jul 17, 2014 at 06:25:26PM +0100, Will Deacon wrote:
On Thu, Jul 17, 2014 at 04:59:10PM +0100, Alexei Starovoitov wrote:
On Thu, Jul 17, 2014 at 2:19 AM, Will Deacon will.dea...@arm.com wrote:
On
(resending this email in case the first one got caught in your spam
filter. sorry.)
On Thu, Jul 17, 2014 at 10:41:02AM +0100, Will Deacon wrote:
On Wed, Jul 16, 2014 at 11:04:22PM +0100, Zi Shen Lim wrote:
On Wed, Jul 16, 2014 at 05:17:15PM +0100, Will Deacon wrote:
On Tue, Jul 15, 2014 at
On Tue, Jul 8, 2014 at 2:24 AM, Alexei Starovoitov wrote:
> On Tue, Jul 8, 2014 at 12:06 AM, Zi Shen Lim wrote:
[...]
>> Also, per discussion with Alexei, and additional suggestion from
>> Daniel:
>> - moved load_pointer() from net/core/filter.c into filter.h
>> as bpf_load_pointer()
On Tue, Jul 8, 2014 at 2:24 AM, Alexei Starovoitov a...@plumgrid.com wrote:
On Tue, Jul 8, 2014 at 12:06 AM, Zi Shen Lim zlim@gmail.com wrote:
[...]
Also, per discussion with Alexei, and additional suggestion from
Daniel:
- moved load_pointer() from net/core/filter.c into filter.h
Hi Will,
On Thu, Jul 3, 2014 at 2:14 AM, Will Deacon wrote:
> Hello,
>
> On Wed, Jul 02, 2014 at 06:20:24AM +0100, Zi Shen Lim wrote:
[...]
>
> First off, this is really cool. Thanks for putting in the effort to get this
> supported on arm64! I'm happy to run tests on some real hardware if you
Hi Will,
On Thu, Jul 3, 2014 at 2:14 AM, Will Deacon will.dea...@arm.com wrote:
Hello,
On Wed, Jul 02, 2014 at 06:20:24AM +0100, Zi Shen Lim wrote:
[...]
First off, this is really cool. Thanks for putting in the effort to get this
supported on arm64! I'm happy to run tests on some real
On Thu, Jul 3, 2014 at 1:10 AM, Daniel Borkmann wrote:
> Hi Zi,
>
>
> On 07/03/2014 09:52 AM, Zi Shen Lim wrote:
>>
>> load_pointer() is already a static inline function.
>> Let's move it into filter.h so BPF JIT implementations can reuse this
>> function.
>>
>> Signed-off-by: Zi Shen Lim
>> ---
On Thu, Jul 3, 2014 at 1:10 AM, Daniel Borkmann dbork...@redhat.com wrote:
Hi Zi,
On 07/03/2014 09:52 AM, Zi Shen Lim wrote:
load_pointer() is already a static inline function.
Let's move it into filter.h so BPF JIT implementations can reuse this
function.
Signed-off-by: Zi Shen Lim
On Wed, Jul 2, 2014 at 9:57 PM, Z Lim wrote:
> On Wed, Jul 2, 2014 at 2:28 PM, Alexei Starovoitov wrote:
>> On Tue, Jul 1, 2014 at 10:20 PM, Zi Shen Lim wrote:
>> Do you really need 'jump by register' then? Regular 'bl' would be much
>> faster.
>
> We'll need
On Wed, Jul 2, 2014 at 2:28 PM, Alexei Starovoitov wrote:
> On Tue, Jul 1, 2014 at 10:20 PM, Zi Shen Lim wrote:
>> The JIT compiler emits A64 instructions. It supports eBPF only.
>> Legacy BPF is supported thanks to conversion by BPF core.
>>
>> JIT is enabled in the same way as for other
On Wed, Jul 2, 2014 at 2:28 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Tue, Jul 1, 2014 at 10:20 PM, Zi Shen Lim zlim@gmail.com wrote:
The JIT compiler emits A64 instructions. It supports eBPF only.
Legacy BPF is supported thanks to conversion by BPF core.
JIT is enabled in the
On Wed, Jul 2, 2014 at 9:57 PM, Z Lim zlim@gmail.com wrote:
On Wed, Jul 2, 2014 at 2:28 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Tue, Jul 1, 2014 at 10:20 PM, Zi Shen Lim zlim@gmail.com wrote:
Do you really need 'jump by register' then? Regular 'bl' would be much
faster
64 matches
Mail list logo