(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, 2014
(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, 201
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 phase
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 ca
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 CONFIG_DEBUG_SET_M
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 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 archite
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.
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 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()
>>
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 te
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:
>>
>> Acked-
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 a
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 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 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
> con
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 function call so it m
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 need
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
> ch
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
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
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 po
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 is
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 correspondin
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, impleme
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, th
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 may
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 = bpf2a
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 unsubscri
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 f
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:
>> https://github.com/0day-ci/linux/commits/Zi-Shen-Lim/arm64-bpf-implement-bpf_tail_call-helper/20160605-060
32 matches
Mail list logo
