Re: [PATCH RFC bpf-next 2/3] bpf: Fix bpf_sk_lookup.remote_port on big-endian

[Jakub Sitnicki <jakub@cloudflare.com>]

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/