LLVM regression in memcpy struct bpf_sock_ops->remote_ip6 to struct in6_addr

LLVM regression in memcpy struct bpf_sock_ops->remote_ip6 to struct in6_addr

[YiFei Zhu]

In one of our BPF progs, there is a pattern of copying IPv6 addresses
(which are four u32s) off of struct bpf_sock_ops into a stack variable
(a larger struct that contains struct in6_addr), then updating a map
with that stack variable. After a recent LLVM upgrade, that program no
longer loads.

I wrote a reproducer:

  #include <string.h>
  #include <linux/in6.h>
  #include <linux/bpf.h>
  #include <bpf/bpf_helpers.h>

  struct in6_addr addr6;

  SEC("sockops")
  int test(struct bpf_sock_ops *skops)
  {
          struct in6_addr stack_addr6;

          memcpy(&stack_addr6, skops->remote_ip6, sizeof(skops->remote_ip6));
          addr6 = stack_addr6;
          return 0;
  }

This will fail loading at latest LLVM main with error:

  -- BEGIN PROG LOAD LOG --
  0: R1=ctx() R10=fp0
  0: (7b) *(u64 *)(r10 -8) = r1         ; R1=ctx() R10=fp0 fp-8=ctx()
  1: (79) r1 = *(u64 *)(r10 -8)         ; R1=ctx() R10=fp0 fp-8=ctx()
  2: (79) r2 = *(u64 *)(r1 +40)
  invalid bpf_context access off=40 size=8
  processed 3 insns (limit 1000000) max_states_per_insn 0 total_states
0 peak_states 0 mark_read 0
  -- END PROG LOAD LOG --

It seems that the program is reading the address from the bpf_sock_ops
as two u64s instead of four u32s, and the verifier understandably does
not allow that due to the complexity of rewriting context accesses. I
bisected the regression to

  commit 790f0623411d5d9d5c989f14e87f2fe86f52eaf3
  Author: Ömer Sinan Ağacan <omeragacan@gmail.com>
  Date:   Tue Jun 9 16:03:26 2026

      [SelectionDAG] Pass dest and src alignments separately to memcpy
and memmove lowering functions (#201119)

Looking at its PR [1], it seems that commit caused another regression
for BPF selftests and that has been fixed, but this regression is
still reproducible on main with that fix applied.

I'm not really familiar enough with LLVM internals to understand
exactly why it generates the code this way or how to fix the
regression.

YiFei Zhu

[1] https://github.com/llvm/llvm-project/pull/201119

Re: LLVM regression in memcpy struct bpf_sock_ops->remote_ip6 to struct in6_addr

[Yonghong Song]

On 7/21/26 4:56 PM, YiFei Zhu wrote:
> In one of our BPF progs, there is a pattern of copying IPv6 addresses
> (which are four u32s) off of struct bpf_sock_ops into a stack variable
> (a larger struct that contains struct in6_addr), then updating a map
> with that stack variable. After a recent LLVM upgrade, that program no
> longer loads.
>
> I wrote a reproducer:
>
>    #include <string.h>
>    #include <linux/in6.h>
>    #include <linux/bpf.h>
>    #include <bpf/bpf_helpers.h>
>
>    struct in6_addr addr6;
>
>    SEC("sockops")
>    int test(struct bpf_sock_ops *skops)
>    {
>            struct in6_addr stack_addr6;
>
>            memcpy(&stack_addr6, skops->remote_ip6, sizeof(skops->remote_ip6));
>            addr6 = stack_addr6;
>            return 0;
>    }
>
> This will fail loading at latest LLVM main with error:
>
>    -- BEGIN PROG LOAD LOG --
>    0: R1=ctx() R10=fp0
>    0: (7b) *(u64 *)(r10 -8) = r1         ; R1=ctx() R10=fp0 fp-8=ctx()
>    1: (79) r1 = *(u64 *)(r10 -8)         ; R1=ctx() R10=fp0 fp-8=ctx()
>    2: (79) r2 = *(u64 *)(r1 +40)
>    invalid bpf_context access off=40 size=8
>    processed 3 insns (limit 1000000) max_states_per_insn 0 total_states
> 0 peak_states 0 mark_read 0
>    -- END PROG LOAD LOG --

Are you using -O0 compile flag? The above code is not optimal.

I tried with llvm23/-O2, cpu v3, and get the following code:

        0:       w2 = *(u32 *)(r1 + 0x2c)
        1:       r3 = 0x0 ll
                 0000000000000008:  R_BPF_64_64  addr6
        3:       *(u32 *)(r3 + 0xc) = w2
        4:       w2 = *(u32 *)(r1 + 0x28)
        5:       *(u32 *)(r3 + 0x8) = w2
        6:       w2 = *(u32 *)(r1 + 0x24)
        7:       *(u32 *)(r3 + 0x4) = w2
        8:       w1 = *(u32 *)(r1 + 0x20)
        9:       *(u32 *)(r3 + 0x0) = w1
       10:       w0 = 0x0
       11:       exit

>
> It seems that the program is reading the address from the bpf_sock_ops
> as two u64s instead of four u32s, and the verifier understandably does
> not allow that due to the complexity of rewriting context accesses. I
> bisected the regression to
>
>    commit 790f0623411d5d9d5c989f14e87f2fe86f52eaf3
>    Author: Ömer Sinan Ağacan <omeragacan@gmail.com>
>    Date:   Tue Jun 9 16:03:26 2026
>
>        [SelectionDAG] Pass dest and src alignments separately to memcpy
> and memmove lowering functions (#201119)
>
> Looking at its PR [1], it seems that commit caused another regression
> for BPF selftests and that has been fixed, but this regression is
> still reproducible on main with that fix applied.
>
> I'm not really familiar enough with LLVM internals to understand
> exactly why it generates the code this way or how to fix the
> regression.
>
> YiFei Zhu
>
> [1] https://github.com/llvm/llvm-project/pull/201119
>