Improve developer experience with ebpf testdata

[simonswine]

I noticed that the git submodule in ebpf/testdata, will always be marked changed when you are on a case-insensitive file system/volume:

on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'qemu_img/amd64/modules_extra/5.10.205-195.807.amzn2.x86_64/kernel/net/netfilter/xt_DSCP.ko'
  'qemu_img/amd64/modules_extra/5.10.205-195.807.amzn2.x86_64/kernel/net/netfilter/xt_dscp.ko'
  'qemu_img/amd64/modules_extra/5.10.205-195.807.amzn2.x86_64/kernel/net/netfilter/xt_HL.ko'
  'qemu_img/amd64/modules_extra/5.10.205-195.807.amzn2.x86_64/kernel/net/netfilter/xt_hl.ko'
  'qemu_img/amd64/modules_extra/5.10.205-195.807.amzn2.x86_64/kernel/net/netfilter/xt_RATEEST.ko'
  'qemu_img/amd64/modules_extra/5.10.205-195.807.amzn2.x86_64/kernel/net/netfilter/xt_rateest.ko'
  'qemu_img/amd64/modules_extra/5.10.205-195.807.amzn2.x86_64/kernel/net/netfilter/xt_TCPMSS.ko'
  'qemu_img/amd64/modules_extra/5.10.205-195.807.amzn2.x86_64/kernel/net/netfilter/xt_tcpmss.ko'
  'qemu_img/arm64/modules_extra/5.10.205-195.807.amzn2.aarch64/kernel/net/netfilter/xt_DSCP.ko'
  'qemu_img/arm64/modules_extra/5.10.205-195.807.amzn2.aarch64/kernel/net/netfilter/xt_dscp.ko'
  'qemu_img/arm64/modules_extra/5.10.205-195.807.amzn2.aarch64/kernel/net/netfilter/xt_HL.ko'
  'qemu_img/arm64/modules_extra/5.10.205-195.807.amzn2.aarch64/kernel/net/netfilter/xt_hl.ko'
  'qemu_img/arm64/modules_extra/5.10.205-195.807.amzn2.aarch64/kernel/net/netfilter/xt_RATEEST.ko'
  'qemu_img/arm64/modules_extra/5.10.205-195.807.amzn2.aarch64/kernel/net/netfilter/xt_rateest.ko'
  'qemu_img/arm64/modules_extra/5.10.205-195.807.amzn2.aarch64/kernel/net/netfilter/xt_TCPMSS.ko'
  'qemu_img/arm64/modules_extra/5.10.205-195.807.amzn2.aarch64/kernel/net/netfilter/xt_tcpmss.ko'

See wrong fix and discussion in #3254 and upsteam pyroscope-io/pyroscope-ebpf-testdata#4

Workaround (which is not ideally, as every new contributor has to run it):

$ git update-index --assume-unchanged ebpf/testdata

I wonder what the best way forward:

• Just remove the extra lowercase modules, I am fairly sure those modules are not touched by eBPF tests
• Ship testdata separately from git: Maybe a public object store bucket or using them from a docker image.

cc @aleks-p @korniltsev

[korniltsev]

It looks like they are not used. Let's just remove them? (both cases)

root@pyroscopeebpftestvm:~# uname -a
Linux pyroscopeebpftestvm 5.10.205-195.807.amzn2.aarch64 #1 SMP Tue Jan 16 18:29:00 UTC 2024 aarch64 GNU/Linux
root@pyroscopeebpftestvm:~# lsmod
Module                  Size  Used by
xt_conntrack           16384  1
xt_MASQUERADE          20480  1
nf_conntrack_netlink    53248  0
nfnetlink              20480  2 nf_conntrack_netlink
iptable_nat            16384  1
nf_nat                 49152  2 iptable_nat,xt_MASQUERADE
nf_conntrack          184320  4 xt_conntrack,nf_nat,nf_conntrack_netlink,xt_MASQUERADE
nf_defrag_ipv6         24576  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
xt_addrtype            16384  2
iptable_filter         16384  1
bpfilter               16384  0
br_netfilter           28672  0
bridge                249856  1 br_netfilter
stp                    20480  1 bridge
llc                    20480  2 bridge,stp
ghash_ce               24576  0
sha2_ce                20480  0
sha256_arm64           28672  1 sha2_ce
sha1_ce                20480  0
overlay               131072  0
uio_pdrv_genirq        20480  0
uio                    28672  1 uio_pdrv_genirq
fuse                  163840  1
loop                   40960  0
drm                   659456  0
dm_mod                151552  0
bpf_preload            16384  0
ext4                  892928  1
mbcache                24576  1 ext4
jbd2                  167936  1 ext4
virtio_net             57344  0
net_failover           24576  1 virtio_net
virtio_blk             24576  1
failover               20480  1 net_failover
virtio_pci             28672  0
virtio_mmio            24576  0
virtio_ring            36864  4 virtio_mmio,virtio_pci,virtio_blk,virtio_net
virtio                 24576  4 virtio_mmio,virtio_pci,virtio_blk,virtio_net

[korniltsev]

We can also put modules into tar.gz

[aleks-p]

Either approach sounds good to me. Putting them in an archive will reduce the chance of the problem surfacing again in the future which would be nice.

[korniltsev]

Also having a 4G git submodule may be not a great experience as well