From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f9.google.com (mail-wm2-f9.google.com [74.125.225.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6561C3BFAEB for ; Tue, 28 Jul 2026 17:28:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.137 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785259735; cv=none; b=lmO3naN+Tb1ydydmQ+oIoF22BfS9dPum+PNJrH6SrsCvFZ2KlyLjUnAnd2Xy6bscV+41PUofwWmzSzkFI8MacCE/C2kup4V5zTBHTie2A4nbPXztvpDeGNM2YVRSdmayCHc1ilQmbZt/U2tIllOy2Qon005HYrtQ6i5oBU9sACg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785259735; c=relaxed/simple; bh=kwCGjZwRfWG+1hIQMc0ddiJCm3ytqoes5YMMF/1Scng=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GWoQZh1l8daO1iFaOjFhG9akEvWHPJtYT5Cdy6VmQxf/QjxW5LcQdUjJoFgfv6kgEGjbxCgC+6zLeAKtzWqDt6sHoXmu5RmIVibdeRqW/U4gRBfjgZ5XVWKUcpbqbQSJd9qJJAEKt9Sf3RSrcOHOADz7qB6UZaA5G+INACkYzbU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lMjKV/r2; arc=none smtp.client-ip=74.125.225.137 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lMjKV/r2" Received: by mail-wm2-f9.google.com with SMTP id 5b1f17b1804b1-493e55619a2so129445e9.1 for ; Tue, 28 Jul 2026 10:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785259732; x=1785864532; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=89i5Xg4svJgXBxa+VECmORIi//zfBDN4JU0w7A03jnw=; b=lMjKV/r2Kxcpwlwym84hbydHeevywwzNxiij9E+sTBaCmhXYDcQcEPZB1fKmIxGAG4 8MYYBq2K2eFOr6Rvtwkt9eUIjVFXcBut46ACXtO34SucyXVVDmGRn5LXtrldtx1QUCUs uzf+8DGlTKuHYiz0e7IeAM54cvArjILqHvjl9ni5/qGdDnuyLj5rV5ryALmAMxUUyOVu WcpZu5MDtG00NqETaowzdVf0Ew09ykLcIPOSPLuOXZlGPo0mFAmEVnzjGt48EPXEvQgw 19PHMdOb7atD3yNAEZARn2Lfx1sya0DnFURy8m5ezuj2WrXQ8nO6u7O7NzsnanYndo3B PKCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785259732; x=1785864532; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=89i5Xg4svJgXBxa+VECmORIi//zfBDN4JU0w7A03jnw=; b=CNNX8mRx6ICyqIHUhfBzt6yTSh+w3+C8z6JaFwQKh8DkqoZuutYVn867I4OI9CQqWt QEO75pvQpEXQmOpk/U1PcrrvauoBzhiyy/sWZbZyMToRJZqyA1ysyiIQ1GN7oDpI1i+O NvbUnjWE5Q3L1jcbZOnnHLCPbi/IjsiQ75pqZosoEwtBABg/2edZswgOfLpEf53EgT9i QmTL6CkPEFI30qdOBB4pc7lR97tVPuG7WuCwYI+Ev4JIld74v3+9veVVA4+TZQGWk9ff xI7Vo9zpMbU1FkrRNxoxtp5SwzWILlhif/fpe7G3BlO06//sDSzr0LgsH9p1FTozizmU DtHw== X-Forwarded-Encrypted: i=1; AHgh+RpNg/sffgDvKhPV1fD5gbQVogjmLn+MxamOYZWVP37rzZrxQkiaKIAp10+EX/L9YhIqzVyepSXmxUZ5a5U=@vger.kernel.org X-Gm-Message-State: AOJu0YyYI/mUXUW0Rp3nh45fQ/0937pasqFvwMSzdQjI+kbT3gIAcn0e 3lPUKQp0MteBXya8R7bQXJSyL3VuusTsUxj+9aChh+QXRvh6pcRZN9eI X-Gm-Gg: AR+sD11v/YbiEigscCSXFWRPfmIZwmPLCyppw/MgFvvi/43UtPHN7m/oHj8t14aroEH tO6Y43vN9AT4rpJPKn1R3bmxHlzD5we2QbJSYVn972Y7YOKM6V+JrFIfnSsTDaXsaTaNbYR9oqx g9wR3iWHcVfK05kHkWwa7plratmlLRCN9hf+pQ0Zn7KE+IZth/A+TnrIfYu8ocxokrxI3Ciyknm 3jTkCh7AZOjssyROB91pSOreub2vrXkDRmJLCH9jCdsJNZelryua4hT6v40mPiR5m9Np6KDJMvM eSZw+oTn5Jhu2iAszagZuz8XWTGZ5licPJuyfH+PvZBpTqskQ58QQx5PbYnBDCpKTB9lQO+AsDv XaC+3KSxLNNs/54UKujEhjxTCCjLwpQI2ZHuhxztxpJDo7KfIxPXq+N+UIVmuVw1lP6VOq6JM41 pD/g== X-Received: by 2002:a05:600c:1c1c:b0:493:dcad:84da with SMTP id 5b1f17b1804b1-496c640fc12mr34326075e9.1.1785259731393; Tue, 28 Jul 2026 10:28:51 -0700 (PDT) Received: from fedora ([212.253.220.176]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-496c44af19bsm89418735e9.3.2026.07.28.10.28.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2026 10:28:50 -0700 (PDT) From: Serhat Kumral To: yanjun.zhu@linux.dev Cc: mounter625@163.com, zyjzyj2000@gmail.com, xiongwm2026@163.com, jgg@ziepe.ca, leon@kernel.org, dsahern@kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, serhatkumral1@gmail.com, syzbot+8c9eede336e3a843750e@syzkaller.appspotmail.com Subject: Re: [RFC PATCH 1/2] RDMA/rxe: drive UDP tunnel socket lifetime from the GID table Date: Tue, 28 Jul 2026 20:28:25 +0300 Message-ID: <20260728172825.43978-1-serhatkumral1@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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