Re: [RFC PATCH 1/2] RDMA/rxe: drive UDP tunnel socket lifetime from the GID table

[Serhat Kumral]

> I suggest reproducing the problem locally first, which would help avoid
> a lengthy back-and-forth discussion.

I rebuilt your environment as closely as I could and could not
reproduce the failure.

  base commit  f2ec6312bf71 + this series
  config       your config_linux; "make olddefconfig" changed 15 lines
               (rustc detection and openssl key types; Rust is not
               enabled)
  guest        Fedora 43, rdma-core-58.0-4.fc43, 16 vCPUs, 16 GB
  qemu         q35, virtio-net on a PCIe root port, so the NIC is enp1s0

  [    0.000000] Linux version 7.2.0-rc3-rxe-l2+ (root@210da8ac5887)
    (gcc (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7), GNU ld version
    2.45.1-5.fc43) #2 SMP PREEMPT_DYNAMIC Sat Jul 25 15:08:57 UTC 2026
  [    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009),
    BIOS 1.16.3-debian-1.16.3-2 04/01/2014

Same kernel release string and same DMI line as your Oops, and since
the config is yours, KASAN, lockdep, PROVE_RCU, DEBUG_LIST, KFENCE and
kmemleak are all active. One deliberate difference: the guest runs
SELinux permissive.

What I ran:

  rxe_rping_between_netns.sh from the tree                  120 runs
  the same script with its "exec > /dev/null" removed         3 runs
  make -C tools/testing/selftests TARGETS=rdma run_tests      2 runs

All passed, with no KASAN report, GPF, Oops, refcount warning or
lockdep splat in any of them. The result lines of the suite run:

  ok 1 selftests: rdma: rxe_rping_between_netns.sh
  ok 2 selftests: rdma: rxe_ipv6.sh
  ok 3 selftests: rdma: rxe_socket_with_netns.sh
  ok 4 selftests: rdma: rxe_test_NETDEV_UNREGISTER.sh
  ok 5 selftests: rdma: rxe_sent_rcvd_bytes.sh

To confirm the setup would actually show a memory error, I loaded the
KASAN test module from your own config ("modprobe kunit enable=1;
modprobe kasan_test") in the same guest, and the reports do reach the
console I capture:

  [   66.611585] BUG: KASAN: slab-out-of-bounds in
    kmalloc_oob_right+0x72e/0x7f0 [kasan_test]

The same 120 runs on plain f2ec6312 without the series also pass, so
here neither kernel fails.

Whether what you see is a regression or a pre-existing bug can only be
decided on your VM, since here it does not fail either way. Short of
that run, two things are cheap to produce and would help:

  git log --oneline f2ec6312bf71..HEAD
  cat /proc/cmdline

On the port 4791 question you raised earlier, I measured both sides.
A script binds UDP 4791, then runs "rdma link add rxeC type rxe netdev
v0" on a veth with 10.9.1.1 and prints the exit status, the GID table
and "rdma link". Without this series:

  link add with busy port rc=1
  error: Operation not permitted
  /sys/class/infiniband/rxeC/ports/1/gids/*
  [   99.810196] rdma_rxe: Failed to create IPv4 UDP tunnel

The glob is unexpanded because no device was created. With this
series:

  link add with busy port rc=0
  /sys/class/infiniband/rxeC/ports/1/gids/0 fe80:0000:0000:0000:288a:0cff:fe1c:042d
  /sys/class/infiniband/rxeC/ports/1/gids/1 fe80:0000:0000:0000:8435:54ff:fe3e:1578
  [  100.525123] infiniband rxeC: add_roce_gid GID add failed port=1 index=1
  [  100.529972] __ib_cache_gid_add: unable to add gid
    0000:0000:0000:0000:0000:ffff:0a09:0101 error=-98
  link rxeC/1 state ACTIVE physical_state LINK_UP netdev v0

The GID for 10.9.1.1 is absent, only the link local ones are there.
This is the trade-off the commit message describes, measured on both
sides.

Thanks,
Serhat