On 5/16/2016 4:45 PM, Z Lim wrote:
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
On 5/12/2016 11:37 PM, Zi Shen Lim wrote:
Original implementation commit e54bcde3d69d ("arm64: eBPF JIT compiler")
had the relevant code paths, but due to an oversight always fail jiting.
As a result, we had been falling back to BPF interpreter whenever a BPF
program has JMP_JSET_{X,K} instructi
On 4/22/2016 9:50 PM, Eric Dumazet wrote:
On Fri, 2016-04-22 at 21:02 -0700, Shi, Yang wrote:
Hi David,
When I ran some test on a nfs mounted rootfs, I got the below warning
with LOCKDEP enabled on linux-next-20160420:
WARNING: CPU: 9 PID: 0 at include/net/sock.h:1408
udp_queue_rcv_skb+0x3d0
Hi David,
When I ran some test on a nfs mounted rootfs, I got the below warning
with LOCKDEP enabled on linux-next-20160420:
WARNING: CPU: 9 PID: 0 at include/net/sock.h:1408
udp_queue_rcv_skb+0x3d0/0x660
Modules linked in:
CPU: 9 PID: 0 Comm: swapper/9 Tainted: G D
4.6.0-rc4-next-2016
On 12/17/2015 2:51 PM, Daniel Borkmann wrote:
Back in the days where eBPF (or back then "internal BPF" ;->) was not
exposed to user space, and only the classic BPF programs internally
translated into eBPF programs, we missed the fact that for classic BPF
A and X needed to be cleared. It was fixed
On 11/30/2015 2:24 PM, Yang Shi wrote:
aarch64 doesn't have native store immediate instruction, such operation
has to be implemented by the below instruction sequence:
Load immediate to register
Store register
Signed-off-by: Yang Shi
CC: Zi Shen Lim
Had email exchange offline with Zi Shen L
:
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 m
On 11/18/2015 1:41 PM, Z Lim wrote:
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
On 11/18/2015 12:56 AM, Zi Shen Lim wrote:
During code review, I noticed we were passing a bad buffer pointer
to bpf_load_pointer helper function called by jitted code.
Point to the buffer allocated by JIT, so we don't silently corrupt
other parts of the stack.
Signed-off-by: Zi Shen Lim
---
On 11/16/2015 8:41 PM, Alexei Starovoitov wrote:
On Mon, Nov 16, 2015 at 08:37:11PM -0800, Z Lim wrote:
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.
...
CC: Zi
On 11/13/2015 6:39 PM, Z Lim wrote:
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 r
On 11/12/2015 7:28 PM, Z Lim wrote:
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
On 11/11/2015 4:39 AM, Will Deacon wrote:
On Wed, Nov 11, 2015 at 12:12:56PM +, Will Deacon wrote:
On Tue, Nov 10, 2015 at 06:45:39PM -0800, Z Lim wrote:
On Tue, Nov 10, 2015 at 2:41 PM, Yang Shi wrote:
aarch64 doesn't have native store immediate instruction, such operation
Actually, aa
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, implement it by
the below instruction sequence:
Load (dst + off) to a register
Add src to it
Store it back to (dst + off)
Not really what is
On 11/9/2015 12:00 PM, Z Lim wrote:
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 pro
On 11/8/2015 2:29 PM, Z Lim wrote:
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
Please ignore this one, forgot to cc to linux-arm-kernel list.
Sorry for the inconvenience.
Yang
On 11/6/2015 9:34 PM, 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. Wh
On 11/2/2015 9:24 AM, Steven Rostedt wrote:
On Mon, 02 Nov 2015 09:12:29 -0800
"Shi, Yang" wrote:
Yes, it is common practice for converting sleepable spin lock to raw
spin lock in -rt to avoid scheduling in atomic context bug.
Note, in a lot of cases we don't just convert sp
On 10/31/2015 11:37 AM, Daniel Borkmann wrote:
On 10/31/2015 02:47 PM, Steven Rostedt wrote:
On Fri, 30 Oct 2015 17:03:58 -0700
Alexei Starovoitov wrote:
On Fri, Oct 30, 2015 at 03:16:26PM -0700, Yang Shi wrote:
When running bpf samples on rt kernel, it reports the below warning:
BUG: sleepi
On 11/2/2015 12:59 AM, Thomas Gleixner wrote:
On Sun, 1 Nov 2015, Alexei Starovoitov wrote:
On Sat, Oct 31, 2015 at 09:47:36AM -0400, Steven Rostedt wrote:
On Fri, 30 Oct 2015 17:03:58 -0700
Alexei Starovoitov wrote:
On Fri, Oct 30, 2015 at 03:16:26PM -0700, Yang Shi wrote:
When running bpf
20 matches
Mail list logo
