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

[Zhu Yanjun <yanjun.zhu@linux.dev>]

在 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