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

[Zhu Yanjun]

在 2026/7/27 12:55, 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.

[root@fedora linux]# git log --oneline f2ec6312bf..HEAD
c7b5816e800a (HEAD -> master) Merge branch 'master' of 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
668b9a3b586c RDMA/rxe: Hold netdev reference for transmit skbs

This is the command line
"
[    0.000000] Command line: 
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-7.2.0-rc3-rxe-l2+ 
root=UUID=511002c6-ecb8-4356-bd0b-7c54cc92384f ro rootflags=subvol=root 
rhgb quiet crashkernel=2G
"

Zhu Yanjun

> 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