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

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.

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

thanks,
serhat