From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 585642D6E5A; Tue, 27 Jan 2026 12:00:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769515211; cv=none; b=s++F8N5ebYvi0J1cfWeRPxEO1oYK+3SHIw4Kd86zfvWDNJKiCwl0Pk2S8zps8hE2B48VvPWK/cxDhJ70/IJs+jrzgTNMkw6i5b/cj1MqRXjt/KPw1Nfji90r+SQ6fNEWQFpKfr7if2UzdDdyipj1SbTms1brtR2QoITUZ1sMffI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769515211; c=relaxed/simple; bh=SeLALWDOP83Jw3okDSyIifVylWpRx8J9njxbkkPruig=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZpeHNhW6RWvudHoBGxxJv2U2G6gFupBeFy3PPOXg+XT6+uDWdVAvhTQrQsQAON5un0kmYjHiK4SlYQ2awqVTTJIY2T4V4MtUn4rNpaLFRt60kSBjgLfNl0pn1D/E4PLE+mEHcXixq7hkaZnl33N3gtoEJyvy88ccoviUui98YAA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kB8SrFBV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kB8SrFBV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B45DC116C6; Tue, 27 Jan 2026 12:00:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769515210; bh=SeLALWDOP83Jw3okDSyIifVylWpRx8J9njxbkkPruig=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kB8SrFBVdLcDp1yO21dPiiLLQ4Jr5Ybfy6tLGM2XI/gK2CYW8fjNWg9Du6y4EWrjE 3NIgAi2RQ6740vmp1QbiFheUnoRLQGoFNgH52Lg6XSHChxpK8T7FqMepfIUO4WsCym Xvjaq10fo61gyKaupdnylv2TwW/DKprmwbQbf3U3ghAFss4pj+jFTW8U4E/VF50nHi 5PLaWITS4KnXj324Q22UeEUdk1gSpbbX79StZrHPYLa3IwTrN4wPGo4IQad7iCra3C sOUIXlEgIx0dE4oHDzLwm8fI1j/qbjFBhkNfXWvlYzCB5/3iCGFzJ36oQy4KqWTndo XcLRFyHCiWGyQ== Date: Tue, 27 Jan 2026 14:00:04 +0200 From: Leon Romanovsky To: "D. Wythe" Cc: Liu Jian , dust.li@linux.alibaba.com, sidraya@linux.ibm.com, wenjia@linux.ibm.com, mjambigi@linux.ibm.com, tonylu@linux.alibaba.com, guwen@linux.alibaba.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, guangguan.wang@linux.alibaba.com, linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org, netdev@vger.kernel.org, Christoph Hellwig , Jason Gunthorpe Subject: Re: [PATCH net v2] net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync() Message-ID: <20260127120004.GT13967@unreal> References: <20250828124117.2622624-1-liujian56@huawei.com> <20250909094532.GD341237@unreal> <20260126044501.GA18724@j66a10360.sqa.eu95> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260126044501.GA18724@j66a10360.sqa.eu95> On Mon, Jan 26, 2026 at 12:45:01PM +0800, D. Wythe wrote: > On Tue, Sep 09, 2025 at 12:45:32PM +0300, Leon Romanovsky wrote: > > On Thu, Aug 28, 2025 at 08:41:17PM +0800, Liu Jian wrote: > > > BUG: kernel NULL pointer dereference, address: 00000000000002ec > > > PGD 0 P4D 0 > > > Oops: Oops: 0000 [#1] SMP PTI > > > CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE > > > Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE > > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 > > > Workqueue: smc_hs_wq smc_listen_work [smc] > > > RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc] > > > ... > > > Call Trace: > > > > > > smcr_buf_map_link+0x211/0x2a0 [smc] > > > __smc_buf_create+0x522/0x970 [smc] > > > smc_buf_create+0x3a/0x110 [smc] > > > smc_find_rdma_v2_device_serv+0x18f/0x240 [smc] > > > ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc] > > > smc_listen_find_device+0x1dd/0x2b0 [smc] > > > smc_listen_work+0x30f/0x580 [smc] > > > process_one_work+0x18c/0x340 > > > worker_thread+0x242/0x360 > > > kthread+0xe7/0x220 > > > ret_from_fork+0x13a/0x160 > > > ret_from_fork_asm+0x1a/0x30 > > > > > > > > > If the software RoCE device is used, ibdev->dma_device is a null pointer. > > > As a result, the problem occurs. Null pointer detection is added to > > > prevent problems. > > > > > > Fixes: 0ef69e788411c ("net/smc: optimize for smc_sndbuf_sync_sg_for_device and smc_rmb_sync_sg_for_cpu") > > > Signed-off-by: Liu Jian > > > --- > > > v1->v2: > > > move the check outside of loop. > > > net/smc/smc_ib.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/net/smc/smc_ib.c b/net/smc/smc_ib.c > > > index 53828833a3f7..a42ef3f77b96 100644 > > > --- a/net/smc/smc_ib.c > > > +++ b/net/smc/smc_ib.c > > > @@ -742,6 +742,9 @@ bool smc_ib_is_sg_need_sync(struct smc_link *lnk, > > > unsigned int i; > > > bool ret = false; > > > > > > + if (!lnk->smcibdev->ibdev->dma_device) > > > + return ret; > > > > Please use ib_uses_virt_dma() function for that. > > > > It is clearly stated in the code: > > 2784 struct ib_device { > > 2785 /* Do not access @dma_device directly from ULP nor from HW drivers. */ > > 2786 struct device *dma_device; > > > > Thanks > > > > > > Hi Leon, > > Sorry for the late reply, I just noticed this and thank you for your review. > I agree completely with your feedback: we should not be accessing ibdev->dma_device > directly. Following your advice, replacing the > > if (!lnk->smcibdev->ibdev->dma_device) > > check with ib_uses_virt_dma() is straightforward and absolutely the correct > thing to do for that part of the logic. > > However, this has led me to a further challenge. The main purpose of the > smc_ib_is_sg_need_sync() function is to get the result of dma_need_sync(). > This means that even after correctly using ib_uses_virt_dma(), the function > still needs to call dma_need_sync(ibdev->dma_device, ...), which forces us > right back into the direct access pattern we are trying to eliminate. I would like to challenge the use of dma_need_sync() in smc_ib.c. From what I see, it is used to avoid calls to dma_sync_single_*_device() which will be NOP anyway in that case. Why did you copy that logic from XSK? > > Since the RDMA doesn't currently offer a helper for this "check" functionality, > I'd like to propose adding one. What are your thoughts on a new helper like > the one below, which would allow us to solve this cleanly? > > /* ib_verbs.h */ > static inline bool ib_dma_need_sync(struct ib_device *dev, dma_addr_t dma_addr) { > return !ib_uses_virt_dma(dev) && dma_need_sync(dev->dma_device, dma_addr); > } If we're discussing wrappers, it's likely better to provide a wrapper around dma_sync_sg_for_cpu() for use in ib_dma_sync_sg_for_cpu(), rather than open‑coding the logic. Thanks > > Best wishes, > D. Wythe > >