On Mon, Sep 14, 2020 at 11:28 AM Ilias Apalodimas
wrote:
> Even if that's true, is any reason at all why we should skip the first element
> of the array, that's now needed since 7c2e988f400 to jump back to the first
> instruction?
> Introducing 2 extra if conditions and hotfix the array on the fly
On Mon, Sep 14, 2020 at 10:55 AM Ilias Apalodimas
wrote:
> We've briefly discussed this approach with Yauheni while coming up with the
> posted patch.
> I think that contructing the array correctly in the first place is better.
> Right now it might only be used in bpf2a64_offset() and
> bpf_prog_
On Mon, Sep 14, 2020 at 10:03 AM Ilias Apalodimas
wrote:
> Naresh from Linaro reported it during his tests on 5.8-rc1 as well [1].
> I've included both Jiri and him on the v2 as reporters.
>
> [1] https://lkml.org/lkml/2020/8/11/58
I'm curious what you think of Luke's earlier patch to this bug:
13.063704 ] [] __do_sys_bpf+0x766/0x13b4
> [ 13.063840 ] [] sys_bpf+0xc/0x14
> [ 13.063961 ] [] ret_from_syscall+0x0/0x2
>
> The new code is also simpler to understand and includes an ASCII diagram
> of the stack layout.
>
> Tested on riscv32 QEMU virt machine.
>
> Signed-off-by: Luke Nelson
Thanks for the fix!
Acked-by: Xi Wang
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: Xi
Currently "ALU_END_FROM_BE 32" and "ALU_END_FROM_LE 32" do not test if
the upper bits of the result are zeros (the arm64 JIT had such bugs).
Extend the two tests to catch this.
Acked-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
Signed-off-by: Xi Wang
---
See the ar
Currently "ALU_END_FROM_BE 32" and "ALU_END_FROM_LE 32" do not test if
the upper bits of the result are zeros (the arm64 JIT had such bugs).
Extend the two tests to catch this.
Cc: Alexei Starovoitov
Signed-off-by: Xi Wang
---
See the arm64 JIT bugs:
https://lkml.or
