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

[Serhat Kumral]

I was pointed at Weimin Xiong's "RDMA/rxe: Hold netdev reference for
transmit skbs" (v3, 20260716055255.157674-1-xiongwm2026@xxxxxxx) and
tested with it applied.

That patch and this series conflict in rxe_notify(). Its hunk carries
"rxe_net_del(&rxe->ib_dev);" as a context line, and this series removes
that call together with the function, so neither order applies with a
plain git apply. I resolved it by keeping both rxe_flush_qps() calls and
dropping the rxe_net_del() line:

	case NETDEV_GOING_DOWN:
		/* Start draining TX queues before the netdev disappears. */
		rxe_flush_qps(rxe);
		break;
	case NETDEV_UNREGISTER:
		rxe_flush_qps(rxe);
		ib_unregister_device_queued(&rxe->ib_dev);
		break;

If the tree where the crash appears resolves it differently, that
difference is worth seeing.

Four kernels on f2ec6312bf71, same config and toolchain as before, 120
runs of rxe_rping_between_netns.sh each:

  f2ec6312bf71                            120/120
  + this series                           120/120
  + the netdev reference patch            120/120
  + the netdev reference patch + series   120/120

No KASAN report, GPF, Oops, refcount warning, lockdep splat, hung task or
RCU stall in any of them. The module symbol tables confirm each kernel
carries what it should: rxe_flush_qps only in the two with the netdev
reference patch, rxe_add_gid and rxe_del_gid only in the two with this
series.

Four kernels reporting nothing made me doubt the setup rather than the
result, so I checked that it reports faults at all: a deliberate NULL
pointer dereference injected into the rxe transmit path, during the same
selftest, gives

  [   69.131350] Oops: general protection fault, kernel NULL pointer
    dereference 0x39: 0000 [#1] SMP KASAN NOPTI
  [   69.141660] Workqueue: rxe_wq do_work [rdma_rxe]

It reaches the console I capture, my filters count it, and the iteration
is recorded as failed. From userspace the selftest just hangs.

So it still does not reproduce here.

thanks,
serhat