From nobody Mon Jun 8 03:17:05 2026 Received: from outbound.baidu.com (mx22.baidu.com [220.181.50.185]) by smtp.subspace.kernel.org (Postfix) with SMTP id DEAB53CB8FD for ; Tue, 2 Jun 2026 09:48:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.181.50.185 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780393736; cv=none; b=ivGxrdSosnmtNy8rNM2EYFiE3M7tjMS6Jlf1MOVsKZPrbKW0ykqKJTEJ+lijF5DkVkgQcWEGsE9RFAw4fcXc/0MCj+vq2KmTwrBivo37Gii5sYfWDc/EFRcqyBOD8Hevy+imn6GSH2hX52hlzjhsMnQ83oXacCJWWABRFWBiImg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780393736; c=relaxed/simple; bh=qx7LAsMT+1/8BfzDVmrovHiV8WAtJsHvCOKi5RmKS+A=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Za+gqLHe3hovMjJowqI2kBIoXoSa4cPbfIhFar6XHOPNECkTLGZkHBfA2bLoV3AsEcupaZHI4y+qsZ6DE7egf3mExMJJpaHt1o7GJ+9c/ZdVyGLWvyM1rIln6Xtxx8rBlMrZsz/qrheI+gALCmVClHeQ00h+uBXfEMzNrqjnBEE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=baidu.com; spf=pass smtp.mailfrom=baidu.com; dkim=fail (0-bit key) header.d=baidu.com header.i=@baidu.com header.b=kgQExwlD reason="key not found in DNS"; arc=none smtp.client-ip=220.181.50.185 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=baidu.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baidu.com Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=baidu.com header.i=@baidu.com header.b="kgQExwlD" X-MD-Sfrom: lirongqing@baidu.com X-MD-SrcIP: 172.31.50.47 From: "Li,Rongqing" To: Logan Gunthorpe , Robin Murphy , Joerg Roedel , Will Deacon , Lu Baolu , Luis Chamberlain , Leon Romanovsky , Bjorn Helgaas , "iommu@lists.linux.dev" , "linux-kernel@vger.kernel.org" CC: "hch@lst.de" Subject: =?utf-8?B?562U5aSNOiBb5aSW6YOo6YKu5Lu2XSBSZTogW1BBVENIXSBpb21tdS9kbWEt?= =?utf-8?B?aW9tbXU6IEZpeCB3cm9uZyBzY2F0dGVybGlzdCBsZW5ndGggYXNzaWdubWVu?= =?utf-8?Q?t_in_P2PDMA_path?= Thread-Topic: =?utf-8?B?W+WklumDqOmCruS7tl0gUmU6IFtQQVRDSF0gaW9tbXUvZG1hLWlvbW11OiBG?= =?utf-8?B?aXggd3Jvbmcgc2NhdHRlcmxpc3QgbGVuZ3RoIGFzc2lnbm1lbnQgaW4gUDJQ?= =?utf-8?Q?DMA_path?= Thread-Index: AQHc8CeCWq5soguHakyPgVn1i3dxJrYpWbGAgAFzGHCAADutkA== Date: Tue, 2 Jun 2026 09:48:44 +0000 Message-ID: References: <20260530112852.2321-1-lirongqing@baidu.com> <5e2f30a4121e4672ab309460630d011b@baidu.com> In-Reply-To: <5e2f30a4121e4672ab309460630d011b@baidu.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baidu.com; s=selector1; t=1780393726; bh=qx7LAsMT+1/8BfzDVmrovHiV8WAtJsHvCOKi5RmKS+A=; h=From:To:CC:Subject:Date:Message-ID:Content-Type; b=kgQExwlDR1JBUybcjHu3OclsgwW5woUSKNORymbSaxV4iKlW/ax5LKcFsgWJwX5Db BZiVC7P1x7xw3CinglCXcxxGNL49AyEHix/E4ccAwBi3E26WmhOXpJcBVjYyHnLvXe aTh3YlD63KX3feu11EzvJIF3YCU38CM3zvOTNMoV6bQYNdigz+QzJzD5n24ID/mP/U P0tLUnjJMLtUIOoPbLubJLTkIKvL7WhARqVXrUZ62F9x6UHd6kBAR5kFLZHadE8KqX /R+8b2aPbfRxCMrJJ2GQqLBgfYY9p/QdRc5or9vcFwmnTiHAabGf15YXvmtiVyKIUz 4Nnh5NrFaOUIg== >=20 > > On 2026-05-30 05:28, lirongqing wrote: > > > From: Li RongQing > > > > > > In iommu_dma_map_sg(), when handling PCI P2PDMA cases, the DMA > > length > > > of the current scatterlist segment `s` is incorrectly assigned from > > > the head entry `sg->length` instead of the current entry `s->length`. > > > > > > This typo causes all P2PDMA segments in the scatterlist to inherit > > > the length of the first segment, leading to corrupted DMA lengths > > > for > > > multi- segment scatterlists. > > > > > > Fix this by using `s->length` instead of `sg->length`. > > > > > > Fixes: a25e7962db ("PCI/P2PDMA: Refactor the p2pdma mapping > > > helpers") > > > Signed-off-by: Li RongQing > > > > Hmm, I thought I had tested this stuff pretty thoroughly so I'm > > surprised I missed that. But I guess seeing the users of these > > specifically don't allow mixing with anonymous memory the vast > > majority of tests would only have one segment. > > > > Can you confirm that you've reproduced and tested this and it actually > > fixes a bug? Not just seeing something that looks strange. I have a > > vague feeling it was intentional but looking at the code it looks wrong= to > me too. > > > > Thanks, > > > Cc: Christoph Hellwig >=20 > Thanks for your feedback! >=20 > This was found via code inspection. You are right that if nents =3D=3D 1,= or if > nents > 1 but all segments happen to have the exact same length, this typo > remains benign by pure coincidence. >=20 > However, for a multi-segment scatterlist with varying lengths (e.g., a sh= ort > 2KB head segment followed by standard 4KB segments), sg_dma_len(s) will > mistakenly assign the 2KB head length to all subsequent 4KB segments. This > will inevitably lead to silent data truncation or IOMMU page faults. >=20 > Since sg_phys(s) correctly takes the current segment's address, sg_dma_le= n(s) > should definitely use s->length to match it. >=20 > I don't have a specific P2PDMA test rig to force multi-segment lists on h= and > right now, but the typo and its impact on varied segment lengths seem > deterministic. >=20 > Thanks >=20 AI report this commit a25e7962db0d79 ("PCI/P2PDMA: Refactor the p2pdma mapp= ing helpers") has other issue, sg->dma_address is uninitialized in case of = PCI_P2PDMA_MAP_THRU_HOST_BRIDGE in kernel/dma/direct.c, a possible fix is b= elow: diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 583c592..4391b79 100644 Reviewed-by: Logan Gunthorpe --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -476,7 +476,7 @@ int dma_direct_map_sg(struct device *dev, struct scatte= rlist *sgl, int nents, * must be mapped with CPU physical address and not= PCI * bus addresses. */ - break; + fallthrough; case PCI_P2PDMA_MAP_NONE: need_sync =3D true; sg->dma_address =3D dma_direct_map_phys(dev, sg_phy= s(sg), thanks [Li,Rongqing]=20