bpf: fix _htons occurences in test_progs
Dave reported that on sparc test_progs generates buggy swapped eth->h_proto protocol comparisons: 10: (15) if r3 == 0xdd86 goto pc+9 R0=imm2,min_value=2,max_value=2 R1=pkt(id=0,off=0,r=14) R2=pkt_end R3=inv R4=pkt(id=0,off=14,r=14) R5=inv56 R10=fp This is due to the unconditional ... #define htons __builtin_bswap16 #define ntohs __builtin_bswap16 ... in test_progs that causes this. Make use of asm/byteorder.h and use __constant_htons() where possible and only perform the bswap16 when on little endian in non-constant case. Fixes:6882804c91
("selftests/bpf: add a test for overlapping packet range checks") Fixes:3782161362
("selftests/bpf: add l4 load balancer test based on sched_cls") Reported-by: David S. Miller <davem@davemloft.net> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:

committed by
David S. Miller

parent
d24f7c7fb9
commit
43bcf707cc
@@ -30,8 +30,6 @@ typedef __u16 __sum16;
|
||||
#include "test_iptunnel_common.h"
|
||||
#include "bpf_util.h"
|
||||
|
||||
#define _htons __builtin_bswap16
|
||||
|
||||
static int error_cnt, pass_cnt;
|
||||
|
||||
#define MAGIC_BYTES 123
|
||||
@@ -42,10 +40,10 @@ static struct {
|
||||
struct iphdr iph;
|
||||
struct tcphdr tcp;
|
||||
} __packed pkt_v4 = {
|
||||
.eth.h_proto = _htons(ETH_P_IP),
|
||||
.eth.h_proto = bpf_htons(ETH_P_IP),
|
||||
.iph.ihl = 5,
|
||||
.iph.protocol = 6,
|
||||
.iph.tot_len = _htons(MAGIC_BYTES),
|
||||
.iph.tot_len = bpf_htons(MAGIC_BYTES),
|
||||
.tcp.urg_ptr = 123,
|
||||
};
|
||||
|
||||
@@ -55,9 +53,9 @@ static struct {
|
||||
struct ipv6hdr iph;
|
||||
struct tcphdr tcp;
|
||||
} __packed pkt_v6 = {
|
||||
.eth.h_proto = _htons(ETH_P_IPV6),
|
||||
.eth.h_proto = bpf_htons(ETH_P_IPV6),
|
||||
.iph.nexthdr = 6,
|
||||
.iph.payload_len = _htons(MAGIC_BYTES),
|
||||
.iph.payload_len = bpf_htons(MAGIC_BYTES),
|
||||
.tcp.urg_ptr = 123,
|
||||
};
|
||||
|
||||
|
Reference in New Issue
Block a user