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

From: Zhu Yanjun

Date: Tue Jul 28 2026 - 23:21:47 EST


在 2026/7/28 10:28, Serhat Kumral 写道:
The crash reproduces here now, and it does not come from this series.

The tree in that git diff carries v2 of "RDMA/rxe: Hold netdev reference
for transmit skbs", not the v3 I was pointed at. The pre-image blob of
rxe_net.c in the diff is 44a16cb1601a, and on f2ec6312bf71:

v2 applied -> rxe_net.c 44a16cb1601a
v3 applied -> rxe_net.c 86c9b19f65e1

v2 alone, without this series, crashes on the first run of
rxe_rping_between_netns.sh:

[ 67.227061] Oops: general protection fault, probably for
non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
[ 67.231014] KASAN: null-ptr-deref in range
[0x0000000000000000-0x0000000000000007]
[ 67.240200] Workqueue: rxe_wq do_work [rdma_rxe]
[ 67.241906] RIP: 0010:ip_rcv+0xeb/0x570

Same fault, same RIP, same Code bytes and same call trace as the oops
reported in this thread, down to process_backlog+0x341/0x1110 and
net_rx_action+0x87e/0xe00.

Runs of rxe_rping_between_netns.sh on f2ec6312bf71:

f2ec6312bf71 120/120
+ this series 120/120
+ v3 120/120
+ v3 + this series 220/220
+ v2 crash on run 1
+ v2 + this series crash on run 1

The mechanism is the one the v3 changelog describes. v2 releases the
netdev through the live skb->dev and then clears it,

if (skb->dev) {
dev_put(skb->dev);
skb->dev = NULL;
}

but skb->dev has already been rewritten by the transmit path, so the put
lands on the wrong device and the receive side can find skb->dev == NULL.
v3 keeps the held netdev in skb_shinfo(skb)->destructor_arg and never
touches skb->dev.

Hi Serhat,

Thanks for the detailed analysis and testing.

I removed this patch from my tree, and the crash no longer reproduces. This confirms that the regression comes from the v2 version of "RDMA/rxe: Hold netdev reference for transmit skbs", not from this series.

The root cause analysis looks correct. Since skb->dev can be modified during the transmit path, using it to store the held netdev reference can result in releasing the wrong device reference. The v3 approach of storing the reference in skb_shinfo(skb)->destructor_arg avoids this issue.

I will take a closer look at the related code paths and continue the review.

Thanks again for the help.

Best regards,
Yanjun


So v3 is the one to carry. Nothing here points at the socket lifetime
change.

thanks,
serhat