| Message ID | 20220222182559.2865596-3-iii@linux.ibm.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | BPF |
| Headers | show |
| Series | bpf_sk_lookup.remote_port fixes | expand |
On Tue, Feb 22, 2022 at 07:25:58PM +0100, Ilya Leoshkevich wrote: > On big-endian, the port is available in the second __u16, not the first > one. Therefore, provide a big-endian-specific definition that reflects > that. Also, define remote_port_compat in order to have nicer > architecture-agnostic code in the verifier and in tests. > > Fixes: 9a69e2b385f4 ("bpf: Make remote_port field in struct bpf_sk_lookup 16-bit wide") > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> > --- > include/uapi/linux/bpf.h | 17 +++++++++++++++-- > net/core/filter.c | 5 ++--- > tools/include/uapi/linux/bpf.h | 17 +++++++++++++++-- > 3 files changed, 32 insertions(+), 7 deletions(-) > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > index afe3d0d7f5f2..7b0e5efa58e0 100644 > --- a/include/uapi/linux/bpf.h > +++ b/include/uapi/linux/bpf.h > @@ -10,6 +10,7 @@ > > #include <linux/types.h> > #include <linux/bpf_common.h> > +#include <asm/byteorder.h> > > /* Extended instruction set based on top of classic BPF */ > > @@ -6453,8 +6454,20 @@ struct bpf_sk_lookup { > __u32 protocol; /* IP protocol (IPPROTO_TCP, IPPROTO_UDP) */ > __u32 remote_ip4; /* Network byte order */ > __u32 remote_ip6[4]; /* Network byte order */ > - __be16 remote_port; /* Network byte order */ > - __u16 :16; /* Zero padding */ > + union { > + struct { > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN) > + __be16 remote_port; /* Network byte order */ > + __u16 :16; /* Zero padding */ > +#elif defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN) > + __u16 :16; /* Zero padding */ > + __be16 remote_port; /* Network byte order */ > +#else > +#error unspecified endianness > +#endif > + }; > + __u32 remote_port_compat; Sorry this hack is not an option. Don't have any suggestions at this point. Pls come up with something else.
On Sat, Feb 26, 2022 at 06:44 PM -08, Alexei Starovoitov wrote: > On Tue, Feb 22, 2022 at 07:25:58PM +0100, Ilya Leoshkevich wrote: >> On big-endian, the port is available in the second __u16, not the first >> one. Therefore, provide a big-endian-specific definition that reflects >> that. Also, define remote_port_compat in order to have nicer >> architecture-agnostic code in the verifier and in tests. >> >> Fixes: 9a69e2b385f4 ("bpf: Make remote_port field in struct bpf_sk_lookup 16-bit wide") >> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> >> --- >> include/uapi/linux/bpf.h | 17 +++++++++++++++-- >> net/core/filter.c | 5 ++--- >> tools/include/uapi/linux/bpf.h | 17 +++++++++++++++-- >> 3 files changed, 32 insertions(+), 7 deletions(-) >> >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >> index afe3d0d7f5f2..7b0e5efa58e0 100644 >> --- a/include/uapi/linux/bpf.h >> +++ b/include/uapi/linux/bpf.h >> @@ -10,6 +10,7 @@ >> >> #include <linux/types.h> >> #include <linux/bpf_common.h> >> +#include <asm/byteorder.h> >> >> /* Extended instruction set based on top of classic BPF */ >> >> @@ -6453,8 +6454,20 @@ struct bpf_sk_lookup { >> __u32 protocol; /* IP protocol (IPPROTO_TCP, IPPROTO_UDP) */ >> __u32 remote_ip4; /* Network byte order */ >> __u32 remote_ip6[4]; /* Network byte order */ >> - __be16 remote_port; /* Network byte order */ >> - __u16 :16; /* Zero padding */ >> + union { >> + struct { >> +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN) >> + __be16 remote_port; /* Network byte order */ >> + __u16 :16; /* Zero padding */ >> +#elif defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN) >> + __u16 :16; /* Zero padding */ >> + __be16 remote_port; /* Network byte order */ >> +#else >> +#error unspecified endianness >> +#endif >> + }; >> + __u32 remote_port_compat; > > Sorry this hack is not an option. > Don't have any suggestions at this point. Pls come up with something else. I think we can keep the bpf_sk_lookup definition as is, if we leave the 4-byte load from remote_port offset quirky behavior on little-endian. Please take a look at the test fix I've posted for 4-byte load from bpf_sock dst_port that works for me on x86_64 and s390. It is exactly the same case as we're dealing with here: https://lore.kernel.org/bpf/20220227202757.519015-4-jakub@cloudflare.com/T/#u
On Sun, 2022-02-27 at 21:30 +0100, Jakub Sitnicki wrote: > > On Sat, Feb 26, 2022 at 06:44 PM -08, Alexei Starovoitov wrote: > > On Tue, Feb 22, 2022 at 07:25:58PM +0100, Ilya Leoshkevich wrote: > > > On big-endian, the port is available in the second __u16, not the > > > first > > > one. Therefore, provide a big-endian-specific definition that > > > reflects > > > that. Also, define remote_port_compat in order to have nicer > > > architecture-agnostic code in the verifier and in tests. > > > > > > Fixes: 9a69e2b385f4 ("bpf: Make remote_port field in struct > > > bpf_sk_lookup 16-bit wide") > > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> > > > --- > > > include/uapi/linux/bpf.h | 17 +++++++++++++++-- > > > net/core/filter.c | 5 ++--- > > > tools/include/uapi/linux/bpf.h | 17 +++++++++++++++-- > > > 3 files changed, 32 insertions(+), 7 deletions(-) > > > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > > index afe3d0d7f5f2..7b0e5efa58e0 100644 > > > --- a/include/uapi/linux/bpf.h > > > +++ b/include/uapi/linux/bpf.h > > > @@ -10,6 +10,7 @@ > > > > > > #include <linux/types.h> > > > #include <linux/bpf_common.h> > > > +#include <asm/byteorder.h> > > > > > > /* Extended instruction set based on top of classic BPF */ > > > > > > @@ -6453,8 +6454,20 @@ struct bpf_sk_lookup { > > > __u32 protocol; /* IP protocol (IPPROTO_TCP, > > > IPPROTO_UDP) */ > > > __u32 remote_ip4; /* Network byte order */ > > > __u32 remote_ip6[4]; /* Network byte order */ > > > - __be16 remote_port; /* Network byte order */ > > > - __u16 :16; /* Zero padding */ > > > + union { > > > + struct { > > > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : > > > defined(__LITTLE_ENDIAN) > > > + __be16 remote_port; /* Network byte > > > order */ > > > + __u16 :16; /* Zero padding > > > */ > > > +#elif defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : > > > defined(__BIG_ENDIAN) > > > + __u16 :16; /* Zero padding > > > */ > > > + __be16 remote_port; /* Network byte > > > order */ > > > +#else > > > +#error unspecified endianness > > > +#endif > > > + }; > > > + __u32 remote_port_compat; > > > > Sorry this hack is not an option. > > Don't have any suggestions at this point. Pls come up with > > something else. > > I think we can keep the bpf_sk_lookup definition as is, if we leave > the > 4-byte load from remote_port offset quirky behavior on little-endian. > > Please take a look at the test fix I've posted for 4-byte load from > bpf_sock dst_port that works for me on x86_64 and s390. It is exactly > the same case as we're dealing with here: > > https://lore.kernel.org/bpf/20220227202757.519015-4-jakub@cloudflare.com/T/#u > What about 2-byte loads? static __noinline bool sk_dst_port__load_half(struct bpf_sock *sk) { __u16 *half = (__u16 *)&sk->dst_port; return half[0] == bpf_htons(0xcafe); } requires "ca fe ?? ??" in memory on BE, while static __noinline bool sk_dst_port__load_word(struct bpf_sock *sk) { #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ const __u8 SHIFT = 16; #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ const __u8 SHIFT = 0; #else #error "Unrecognized __BYTE_ORDER__" #endif __u32 *word = (__u32 *)&sk->dst_port; return word[0] == bpf_htonl(0xcafe << SHIFT); } requires "00 00 ca fe". This is inconsistent. Furthermore, one cannot see it with bpf_sock thanks to case offsetofend(struct bpf_sock, dst_port) ... offsetof(struct bpf_sock, dst_ip4) - 1: return false; however, with sk_lookup this is the case: loading the most significant half of the port produces non-zero! So, it's not simply a quirkiness of the 4-byte load, it's a mutual inconsistency between LSW loads, MSW loads and 4-byte loads. One might argue that we can live with that, especially since all the user-relevant tests pass - here I can only say that an inconsistency on such a fundamental level makes me nervous. In order to resolve this inconsistency I've implemented patch 1 of this series. With that, "sk->dst_port == bpf_htons(0xcafe)" starts to fail, and that's where one needs something like this patch. Best regards, Ilya
On Mon, Feb 28, 2022 at 11:19 AM +01, Ilya Leoshkevich wrote: > In order to resolve this inconsistency I've implemented patch 1 of this > series. With that, "sk->dst_port == bpf_htons(0xcafe)" starts to fail, > and that's where one needs something like this patch. Truth be told I can't reproduce the said failure. I've extended the test with an additional check: 306 bool ok = sk->dst_port == bpf_htons(0xcafe); 307 if (!ok) 308 RET_LOG(); 309 if (!sk_dst_port__load_word(sk)) 310 RET_LOG(); ... but it translates to the same BPF assembly as sk_dst_port__load_half. That is: ; bool ok = sk->dst_port == bpf_htons(0xcafe); 9: (69) r1 = *(u16 *)(r6 +12) 10: (bc) w1 = w1 ; if (!ok) 11: (16) if w1 == 0xcafe goto pc+2 12: (b4) w1 = 308 13: (05) goto pc+14 During the test I had patch 1 from this series applied on top of [1]. The latter series should not matter, though, I didn't touch the access converter. Mind sharing what does the `bpftool prog objdump` output look like for the failing test on your side? [1] https://lore.kernel.org/bpf/20220227202757.519015-1-jakub@cloudflare.com/
On Mon, 2022-02-28 at 14:26 +0100, Jakub Sitnicki wrote: > On Mon, Feb 28, 2022 at 11:19 AM +01, Ilya Leoshkevich wrote: > > In order to resolve this inconsistency I've implemented patch 1 of > > this > > series. With that, "sk->dst_port == bpf_htons(0xcafe)" starts to > > fail, > > and that's where one needs something like this patch. > > Truth be told I can't reproduce the said failure. > I've extended the test with an additional check: > > 306 bool ok = sk->dst_port == bpf_htons(0xcafe); > 307 if (!ok) > 308 RET_LOG(); > 309 if (!sk_dst_port__load_word(sk)) > 310 RET_LOG(); > > ... but it translates to the same BPF assembly as > sk_dst_port__load_half. That is: > > ; bool ok = sk->dst_port == bpf_htons(0xcafe); > 9: (69) r1 = *(u16 *)(r6 +12) > 10: (bc) w1 = w1 > ; if (!ok) > 11: (16) if w1 == 0xcafe goto pc+2 > 12: (b4) w1 = 308 > 13: (05) goto pc+14 > > During the test I had patch 1 from this series applied on top of [1]. > The latter series should not matter, though, I didn't touch the > access > converter. > > Mind sharing what does the `bpftool prog objdump` output look like > for > the failing test on your side? > > [1] > https://lore.kernel.org/bpf/20220227202757.519015-1-jakub@cloudflare.com/ > Sure. As I mentioned, it's best demonstrated with sk_lookup, so that's what I'll be using. Apply this on top of bpf-next: --- a/tools/testing/selftests/bpf/progs/test_sk_lookup.c +++ b/tools/testing/selftests/bpf/progs/test_sk_lookup.c @@ -392,7 +392,7 @@ int ctx_narrow_access(struct bpf_sk_lookup *ctx) { struct bpf_sock *sk; int err, family; - __u32 val_u32; + __u32 *ptr_u32; bool v4; v4 = (ctx->family == AF_INET); @@ -411,17 +411,12 @@ int ctx_narrow_access(struct bpf_sk_lookup *ctx) if (LSW(ctx->protocol, 0) != IPPROTO_TCP) return SK_DROP; - /* Narrow loads from remote_port field. Expect SRC_PORT. */ - if (LSB(ctx->remote_port, 0) != ((SRC_PORT >> 0) & 0xff) || - LSB(ctx->remote_port, 1) != ((SRC_PORT >> 8) & 0xff) || - LSB(ctx->remote_port, 2) != 0 || LSB(ctx->remote_port, 3) != 0) + ptr_u32 = (__u32 *)&ctx->remote_port; + if (LSW(*ptr_u32, 0) != SRC_PORT) return SK_DROP; - if (LSW(ctx->remote_port, 0) != SRC_PORT) + if (LSW(*ptr_u32, 1) != 0) return SK_DROP; - - /* Load from remote_port field with zero padding (backward compatibility) */ - val_u32 = *(__u32 *)&ctx->remote_port; - if (val_u32 != bpf_htonl(bpf_ntohs(SRC_PORT) << 16)) + if (*ptr_u32 != SRC_PORT) return SK_DROP; /* Narrow loads from local_port field. Expect DST_PORT. */ The checks look as follows: $ llvm-objdump -d -l tools/testing/selftests/bpf/test_sk_lookup.o ; if (LSW(*ptr_u32, 0) != SRC_PORT) 370: 69 26 00 26 00 00 00 00 r2 = *(u16 *)(r6 + 38) 371: 56 20 01 00 00 00 1f 48 if w2 != 8008 goto +256 <LBB15_135> ; if (LSW(*ptr_u32, 1) != 0) 372: 69 26 00 24 00 00 00 00 r2 = *(u16 *)(r6 + 36) 373: 56 20 00 fe 00 00 00 00 if w2 != 0 goto +254 <LBB15_135> ; if (*ptr_u32 != SRC_PORT) 374: 61 26 00 24 00 00 00 00 r2 = *(u32 *)(r6 + 36) 375: 56 20 00 fc 00 00 1f 48 if w2 != 8008 goto +252 <LBB15_135> After loading: # tools/testing/selftests/bpf/tools/sbin/bpftool prog dump xlated id 141 ; if (LSW(*ptr_u32, 0) != SRC_PORT) 49: (69) r2 = *(u16 *)(r6 +4) 50: (bc) w2 = w2 51: (56) if w2 != 0x1f48 goto pc+938 ; if (LSW(*ptr_u32, 1) != 0) 52: (69) r2 = *(u16 *)(r6 +4) 53: (bc) w2 = w2 54: (56) if w2 != 0x0 goto pc+935 ; if (*ptr_u32 != SRC_PORT) 55: (69) r2 = *(u16 *)(r6 +4) 56: (bc) w2 = w2 57: (56) if w2 != 0x1f48 goto pc+932 Note that both LSW(0) and LSW(1) loads result in the same code after rewriting. This is because the offset is ignored for this particular combination of sizes. Best regards, Ilya
On Mon, 2022-02-28 at 14:26 +0100, Jakub Sitnicki wrote: > On Mon, Feb 28, 2022 at 11:19 AM +01, Ilya Leoshkevich wrote: > > In order to resolve this inconsistency I've implemented patch 1 of > > this > > series. With that, "sk->dst_port == bpf_htons(0xcafe)" starts to > > fail, > > and that's where one needs something like this patch. > > Truth be told I can't reproduce the said failure. > I've extended the test with an additional check: > > 306 bool ok = sk->dst_port == bpf_htons(0xcafe); > 307 if (!ok) > 308 RET_LOG(); > 309 if (!sk_dst_port__load_word(sk)) > 310 RET_LOG(); > > ... but it translates to the same BPF assembly as > sk_dst_port__load_half. That is: > > ; bool ok = sk->dst_port == bpf_htons(0xcafe); > 9: (69) r1 = *(u16 *)(r6 +12) > 10: (bc) w1 = w1 > ; if (!ok) > 11: (16) if w1 == 0xcafe goto pc+2 > 12: (b4) w1 = 308 > 13: (05) goto pc+14 > > During the test I had patch 1 from this series applied on top of [1]. > The latter series should not matter, though, I didn't touch the > access > converter. > > Mind sharing what does the `bpftool prog objdump` output look like > for > the failing test on your side? > > [1] > https://lore.kernel.org/bpf/20220227202757.519015-1-jakub@cloudflare.com/ > Sure. As I mentioned, it's best demonstrated with sk_lookup, so that's what I'll be using. Apply this on top of bpf-next: --- a/tools/testing/selftests/bpf/progs/test_sk_lookup.c +++ b/tools/testing/selftests/bpf/progs/test_sk_lookup.c @@ -392,7 +392,7 @@ int ctx_narrow_access(struct bpf_sk_lookup *ctx) { struct bpf_sock *sk; int err, family; - __u32 val_u32; + __u32 *ptr_u32; bool v4; v4 = (ctx->family == AF_INET); @@ -411,17 +411,12 @@ int ctx_narrow_access(struct bpf_sk_lookup *ctx) if (LSW(ctx->protocol, 0) != IPPROTO_TCP) return SK_DROP; - /* Narrow loads from remote_port field. Expect SRC_PORT. */ - if (LSB(ctx->remote_port, 0) != ((SRC_PORT >> 0) & 0xff) || - LSB(ctx->remote_port, 1) != ((SRC_PORT >> 8) & 0xff) || - LSB(ctx->remote_port, 2) != 0 || LSB(ctx->remote_port, 3) != 0) + ptr_u32 = (__u32 *)&ctx->remote_port; + if (LSW(*ptr_u32, 0) != SRC_PORT) return SK_DROP; - if (LSW(ctx->remote_port, 0) != SRC_PORT) + if (LSW(*ptr_u32, 1) != 0) return SK_DROP; - - /* Load from remote_port field with zero padding (backward compatibility) */ - val_u32 = *(__u32 *)&ctx->remote_port; - if (val_u32 != bpf_htonl(bpf_ntohs(SRC_PORT) << 16)) + if (*ptr_u32 != SRC_PORT) return SK_DROP; /* Narrow loads from local_port field. Expect DST_PORT. */ The checks look as follows: $ llvm-objdump -d -l tools/testing/selftests/bpf/test_sk_lookup.o ; if (LSW(*ptr_u32, 0) != SRC_PORT) 370: 69 26 00 26 00 00 00 00 r2 = *(u16 *)(r6 + 38) 371: 56 20 01 00 00 00 1f 48 if w2 != 8008 goto +256 <LBB15_135> ; if (LSW(*ptr_u32, 1) != 0) 372: 69 26 00 24 00 00 00 00 r2 = *(u16 *)(r6 + 36) 373: 56 20 00 fe 00 00 00 00 if w2 != 0 goto +254 <LBB15_135> ; if (*ptr_u32 != SRC_PORT) 374: 61 26 00 24 00 00 00 00 r2 = *(u32 *)(r6 + 36) 375: 56 20 00 fc 00 00 1f 48 if w2 != 8008 goto +252 <LBB15_135> After loading: # tools/testing/selftests/bpf/tools/sbin/bpftool prog dump xlated id 141 ; if (LSW(*ptr_u32, 0) != SRC_PORT) 49: (69) r2 = *(u16 *)(r6 +4) 50: (bc) w2 = w2 51: (56) if w2 != 0x1f48 goto pc+938 ; if (LSW(*ptr_u32, 1) != 0) 52: (69) r2 = *(u16 *)(r6 +4) 53: (bc) w2 = w2 54: (56) if w2 != 0x0 goto pc+935 ; if (*ptr_u32 != SRC_PORT) 55: (69) r2 = *(u16 *)(r6 +4) 56: (bc) w2 = w2 57: (56) if w2 != 0x1f48 goto pc+932 Note that both LSW(0) and LSW(1) loads result in the same code after rewriting. This is because the offset is ignored for this particular combination of sizes. Best regards, Ilya
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index afe3d0d7f5f2..7b0e5efa58e0 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -10,6 +10,7 @@ #include <linux/types.h> #include <linux/bpf_common.h> +#include <asm/byteorder.h> /* Extended instruction set based on top of classic BPF */ @@ -6453,8 +6454,20 @@ struct bpf_sk_lookup { __u32 protocol; /* IP protocol (IPPROTO_TCP, IPPROTO_UDP) */ __u32 remote_ip4; /* Network byte order */ __u32 remote_ip6[4]; /* Network byte order */ - __be16 remote_port; /* Network byte order */ - __u16 :16; /* Zero padding */ + union { + struct { +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN) + __be16 remote_port; /* Network byte order */ + __u16 :16; /* Zero padding */ +#elif defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN) + __u16 :16; /* Zero padding */ + __be16 remote_port; /* Network byte order */ +#else +#error unspecified endianness +#endif + }; + __u32 remote_port_compat; + }; __u32 local_ip4; /* Network byte order */ __u32 local_ip6[4]; /* Network byte order */ __u32 local_port; /* Host byte order */ diff --git a/net/core/filter.c b/net/core/filter.c index 65869fd510e8..4b247d5aebe8 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -10856,8 +10856,7 @@ static bool sk_lookup_is_valid_access(int off, int size, case bpf_ctx_range(struct bpf_sk_lookup, local_ip4): case bpf_ctx_range_till(struct bpf_sk_lookup, remote_ip6[0], remote_ip6[3]): case bpf_ctx_range_till(struct bpf_sk_lookup, local_ip6[0], local_ip6[3]): - case offsetof(struct bpf_sk_lookup, remote_port) ... - offsetof(struct bpf_sk_lookup, local_ip4) - 1: + case bpf_ctx_range(struct bpf_sk_lookup, remote_port_compat): case bpf_ctx_range(struct bpf_sk_lookup, local_port): case bpf_ctx_range(struct bpf_sk_lookup, ingress_ifindex): bpf_ctx_record_field_size(info, sizeof(__u32)); @@ -10938,7 +10937,7 @@ static u32 sk_lookup_convert_ctx_access(enum bpf_access_type type, #endif break; } - case offsetof(struct bpf_sk_lookup, remote_port): + case offsetof(struct bpf_sk_lookup, remote_port_compat): *insn++ = BPF_LDX_MEM(BPF_H, si->dst_reg, si->src_reg, bpf_target_off(struct bpf_sk_lookup_kern, sport, 2, target_size)); diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index afe3d0d7f5f2..7b0e5efa58e0 100644 --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -10,6 +10,7 @@ #include <linux/types.h> #include <linux/bpf_common.h> +#include <asm/byteorder.h> /* Extended instruction set based on top of classic BPF */ @@ -6453,8 +6454,20 @@ struct bpf_sk_lookup { __u32 protocol; /* IP protocol (IPPROTO_TCP, IPPROTO_UDP) */ __u32 remote_ip4; /* Network byte order */ __u32 remote_ip6[4]; /* Network byte order */ - __be16 remote_port; /* Network byte order */ - __u16 :16; /* Zero padding */ + union { + struct { +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN) + __be16 remote_port; /* Network byte order */ + __u16 :16; /* Zero padding */ +#elif defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN) + __u16 :16; /* Zero padding */ + __be16 remote_port; /* Network byte order */ +#else +#error unspecified endianness +#endif + }; + __u32 remote_port_compat; + }; __u32 local_ip4; /* Network byte order */ __u32 local_ip6[4]; /* Network byte order */ __u32 local_port; /* Host byte order */
On big-endian, the port is available in the second __u16, not the first one. Therefore, provide a big-endian-specific definition that reflects that. Also, define remote_port_compat in order to have nicer architecture-agnostic code in the verifier and in tests. Fixes: 9a69e2b385f4 ("bpf: Make remote_port field in struct bpf_sk_lookup 16-bit wide") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> --- include/uapi/linux/bpf.h | 17 +++++++++++++++-- net/core/filter.c | 5 ++--- tools/include/uapi/linux/bpf.h | 17 +++++++++++++++-- 3 files changed, 32 insertions(+), 7 deletions(-)