Fwd: running an eBPF program

Hi,
Is there any way to run this eBPF program without that patch?
Alternatively, is there any other eBPF sample that does run properly?
I need to run a program that filters packets according to IP address
or port.
Thanks,
Adel

On Sun, May 28, 2017 at 8:08 AM, Y Song [off-list ref] wrote:

On Sat, May 27, 2017 at 5:11 PM, David Miller [off-list ref] wrote:

quoted

From: Y Song <redacted>
Date: Sat, 27 May 2017 13:52:27 -0700

quoted

On Sat, May 27, 2017 at 1:23 PM, Y Song [off-list ref] wrote:

quoted

From verifier error message:
======
0: (bf) r6 = r1

1: (18) r9 = 0xffe0000e

3: (69) r0 = *(u16 *)(r6 +16)

invalid bpf_context access off=16 size=2
======

The offset 16 of struct __sk_buff is hash.
What instruction #3 tries to do is to access 2 bytes of the hash value
instead of full 4 bytes.
This is explicitly not allowed in verifier due to endianness issue.

I can reproduce the issue now. My previous statement saying to access
"hash" field is not correct. It is accessing the protocol field.

static __inline__ bool flow_dissector(struct __sk_buff *skb,
                                      struct flow_keys *flow)
{
        int poff, nh_off = BPF_LL_OFF + ETH_HLEN;
        __be16 proto = skb->protocol;
        __u8 ip_proto;

The plan so far is to see whether we can fix the issue in LLVM side.

If the compiler properly asks for "__sk_buff + 16" on little-endian
and "__sk_buff + 20" on big-endian, the verifier should instead be
fixed to allow the access to pass.

I can't see any reason why LLVM won't set the offset properly like
that, and it's a completely legitimate optimization that we shouldn't
try to stop LLVM from performing.

I do agree that such optimization in LLVM is perfect fine and actually
beneficial.
The only reason I was thinking was to avoid introduce endianness into verifier.
Maybe not too much work there. Let me do some experiments and come with
a patch for that.

Thanks!

Yonghong

quoted

It also makes it so that we don't have to fix having absurdly defined
__sk_buff's protocol field as a u32.

Thanks.