From: Alexei Starovoitov
Date: Tue, 18 Apr 2017 15:57:09 -0700
> Alternative idea: can the above
> 'add FP, STACK_BIAS, one_of_local_regs' be done once in prologue
> and that register used as substitue for R10 ?
After much consideration I think this is what I'm going to end up
doing, I should ha
From: Alexei Starovoitov
Date: Fri, 21 Apr 2017 12:26:21 -0700
> It should pick up local headers without touching /usr/include.
> In the past I used to do 'make headers_install' before doing a build
> in samples/bpf or selftests, but then suddenly it started working
> without that step, so I figu
On Fri, Apr 21, 2017 at 03:02:26PM -0400, David Miller wrote:
> From: Alexei Starovoitov
> Date: Fri, 21 Apr 2017 11:49:37 -0700
>
> > On Fri, Apr 21, 2017 at 12:46:40PM -0400, David Miller wrote:
> >> From: Daniel Borkmann
> >> Date: Mon, 17 Apr 2017 20:44:35 +0200
> >>
> >> > There is samples
From: Alexei Starovoitov
Date: Fri, 21 Apr 2017 11:49:37 -0700
> On Fri, Apr 21, 2017 at 12:46:40PM -0400, David Miller wrote:
>> From: Daniel Borkmann
>> Date: Mon, 17 Apr 2017 20:44:35 +0200
>>
>> > There is samples/bpf/sockex3_kern.c, which exercises it. To
>> > run it, it would be (clang/ll
On Fri, Apr 21, 2017 at 12:46:40PM -0400, David Miller wrote:
> From: Daniel Borkmann
> Date: Mon, 17 Apr 2017 20:44:35 +0200
>
> > There is samples/bpf/sockex3_kern.c, which exercises it. To
> > run it, it would be (clang/llvm needed due to BPF backend not
> > available in gcc):
> >
> > # cd sa
On 04/21/2017 06:46 PM, David Miller wrote:
From: Daniel Borkmann
Date: Mon, 17 Apr 2017 20:44:35 +0200
There is samples/bpf/sockex3_kern.c, which exercises it. To
run it, it would be (clang/llvm needed due to BPF backend not
available in gcc):
# cd samples/bpf
# make
# ./sockex3
IP src.p
From: Daniel Borkmann
Date: Mon, 17 Apr 2017 20:44:35 +0200
> There is samples/bpf/sockex3_kern.c, which exercises it. To
> run it, it would be (clang/llvm needed due to BPF backend not
> available in gcc):
>
> # cd samples/bpf
> # make
> # ./sockex3
> IP src.port -> dst.port b
From: Alexei Starovoitov
Date: Tue, 18 Apr 2017 15:57:09 -0700
> On Tue, Apr 18, 2017 at 02:37:32PM -0400, David Miller wrote:
>> From: Alexei Starovoitov
>> Date: Mon, 17 Apr 2017 22:44:47 -0700
>>
>> > The way llvm generates stack access is:
>> > rX = r10
>> > rX += imm
>> > and that's the on
On Tue, Apr 18, 2017 at 02:37:32PM -0400, David Miller wrote:
> From: Alexei Starovoitov
> Date: Mon, 17 Apr 2017 22:44:47 -0700
>
> > The way llvm generates stack access is:
> > rX = r10
> > rX += imm
> > and that's the only thing verifier recognizes as valid ptr_to_stack.
> > Like rX -= imm wil
From: Alexei Starovoitov
Date: Mon, 17 Apr 2017 22:44:47 -0700
> The way llvm generates stack access is:
> rX = r10
> rX += imm
> and that's the only thing verifier recognizes as valid ptr_to_stack.
> Like rX -= imm will not be recognized as proper stack offset,
> since llvm never does it.
That
On Mon, Apr 17, 2017 at 06:12:45PM -0700, David Miller wrote:
> >
> >> + if (insn->src_reg == BPF_REG_FP || insn->dst_reg == BPF_REG_FP) {
> >> + ctx->saw_frame_pointer = true;
> >> + if (BPF_CLASS(code) == BPF_ALU ||
> >> + BPF_CLASS(code) == BPF_ALU64) {
> >> +
From: Alexei Starovoitov
Date: Mon, 17 Apr 2017 16:27:42 -0700
> On Sun, Apr 16, 2017 at 11:38:25PM -0400, David Miller wrote:
>> +static void build_prologue(struct jit_ctx *ctx)
>> +{
>> +s32 stack_needed = 176;
>> +
>> +if (ctx->saw_frame_pointer)
>> +stack_needed += MAX_BPF
On Sun, Apr 16, 2017 at 11:38:25PM -0400, David Miller wrote:
>
> There are a bunch of things I want to do still, and I know that I have
> to attend to sparc32 more cleanly, but I wanted to post this now that
> I have it passing the BPF testsuite completely:
>
> [24174.315421] test_bpf: Summary:
On 04/17/2017 09:03 PM, David Miller wrote:
From: Daniel Borkmann
Date: Mon, 17 Apr 2017 20:44:35 +0200
On 04/17/2017 05:38 AM, David Miller wrote:
+/* Map BPF registers to SPARC registers */
+static const int bpf2sparc[] = {
+ /* return value from in-kernel function, and exit value from eBPF
From: Daniel Borkmann
Date: Mon, 17 Apr 2017 20:44:35 +0200
> On a quick initial glance, you also need to map BPF_REG_AX. If
> I understand the convention correctly, you could use L7 for that.
>
> You can test for it through tools/testing/selftests/bpf/test_kmod.sh
> which exercises the test_bpf
From: Daniel Borkmann
Date: Mon, 17 Apr 2017 20:44:35 +0200
> On 04/17/2017 05:38 AM, David Miller wrote:
>> +/* Map BPF registers to SPARC registers */
>> +static const int bpf2sparc[] = {
>> + /* return value from in-kernel function, and exit value from eBPF */
>> +[BPF_REG_0] = I5,
>> +
>>
On 04/17/2017 05:38 AM, David Miller wrote:
There are a bunch of things I want to do still, and I know that I have
to attend to sparc32 more cleanly, but I wanted to post this now that
I have it passing the BPF testsuite completely:
[24174.315421] test_bpf: Summary: 305 PASSED, 0 FAILED, [297/2
There are a bunch of things I want to do still, and I know that I have
to attend to sparc32 more cleanly, but I wanted to post this now that
I have it passing the BPF testsuite completely:
[24174.315421] test_bpf: Summary: 305 PASSED, 0 FAILED, [297/297 JIT'ed]
Only major unimplemented feature i
18 matches
Mail list logo
