From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj2-f40.google.com (mail-pj2-f40.google.com [74.125.227.168]) (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 B9F2149DBB4 for ; Thu, 24 Sep 2026 14:54:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.168 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790261685; cv=none; b=WXIQAjq77Z3WPIxlaK7EcjcrHN6bTDcspTQP7chS0fnuv4Nr5ah7t/dFNBcZmM/LKXSp2e5Xs8VYo41fyOvnwBTKsv+TpO47gOvddznlmVTX03vTHOykzS5pG36cAWXRnis02+AAE2n5kxbI8DhuPANInycqOO7UPI0u4R1oDCY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790261685; c=relaxed/simple; bh=p1DkMVivDdOboeJjqnejcRbxNjlkIEsanEsxvOaX7h8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=r1x3HLVDec1BCj264L/avsJPLfN9G7Wp+RZaIOQgygAjxaDPqFQ+QtDjhO0g8ZI3a9ouefGNzEvoXdN/oaOJM9066FomFdHStvb1C3OxCg4/YGCDt85nmpOoR3qOTUCIf7cg8kKlLoyvGuAWc/lN2rDEMnJk/WZAM49d3WjO1TI= 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=aTaJmED1; arc=none smtp.client-ip=74.125.227.168 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="aTaJmED1" Received: by mail-pj2-f40.google.com with SMTP id d9443c01a7336-2db425c8ff1so682405ad.0 for ; Thu, 24 Sep 2026 07:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790261670; x=1790866470; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:content-type:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Mo3TPVdoCkIHw8PshUsF9i8x4gaS6XMSbTsYHmyLH0k=; b=aTaJmED178NrdcjrazvolNjDT1PUb8sis1r+R+5xUDrH2U4QdOlVto2NIWCo0mOYuV LqgmlYoZFVx6TH4YLPTB15xvrbrnSdETfJ6nTwPpIG3O0esevUDcAJr935zLGE1kuwix DUGjUAWotnylm5lN/jYRGezXgLIN8g5ECD5N/ClUUAO8InuwftJNz92niW+n2XPAGhGo 5dHR5wS47BBdOvMITlb8swtNy3iIAzLzy2ntrYINar/p0daMMhpIr4e4URSMowmfLnfK /7l3NkMQF2i7plMHK373CUqb5pipQdeBGlBTrF3BdEPsTElCoQ2OSiA6sFW5Lq763Bi9 bJXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790261670; x=1790866470; h=content-transfer-encoding:mime-version:content-type: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=Mo3TPVdoCkIHw8PshUsF9i8x4gaS6XMSbTsYHmyLH0k=; b=XcfvI5bfL+EwHp00N4CZhA46kV6gTV+wS1LYEpxcGFlyn3twr4+4IWHu8KB8cmRHfM uWTGf/MglHyDWWB4UpZHjo97ed7x3YOI13QJ+km+j2Y91qvBwIRBQzcEK27yks2tREME X3/qeNK/U3d9cFDVdGKDPWA4NNpgFFOWp6oJ4izZVWkAnnRWgvi+ekVJ5wg/9t6QRnHX 9eboLBXf84NWcdEa5jyNKXKG5n2R6WxrOdNb94NpndX81j4IX+7gChsFqcryZCiV/goS K5iaI9wTzy+WrZpIX4PjqO31EaLLQr4XeF0GYOCTJXnkYb+puGifet5OMlKPxdm7bnw0 E8IA== X-Forwarded-Encrypted: i=1; AKwUvBzg02luD2fI/FSo72zAr622mLSS7P1OU+gGvZTo2H26u4iyR0NHhkENkq3SmUuI1nmnvYEAK/BaC1IliA==@vger.kernel.org X-Gm-Message-State: AFuF++nYVk12++5zlSG18NPn8bSvF7w6Uu1nUuewwiP/skoFvrScU3V9 e/OEvT3BKqtgYBk4hJJ9SxnDOJiYOIWho8vy4UNfIsQtczrLl8/n58kT X-Gm-Gg: AYBFou2BXcyFbIOtS+KvllNoi/p7l5rjnQuW0L11gWOx6s7j8Rn0UkJIpxgl3YJcYJz p+iRlSyLyEtBhz2cW1qNK50jjYUmzhvKX0yLpCfh/1POEYnSJdqdMUgSYTOspyzlAj5j5DZLnb6 mW09lcMr56F0gFWeQSq5Zgbzj+rcSmLVaLVgk3q0WiWS7h/nbNfMkrdFSy77J7vEFxazCSS+u9I eImh7XnpKTJcBvhI8/c15fkaIZ3ULNj0gYX4riTRDDNZn3fOII9ShPxkQSoQn/OZTn0JTuamUd2 YL4rwHMsTUxnbNwYZLlfg6VtZQeMHsRuztImfyT2i38pEtj6a8htStMt9/20J87p8jxVTFoQfdF BGqx1B7R9FU/3NoBoyxBj/LRx3mTRd/EfRX6ahWyScP7un/vHoI+RR0cBU52h1iJybD2Iwf4wua FrAnaCI8gC9dJ0vWWoX7IWsyCofs0hmKUrZiv1PkhP6KZKTVXpol0JZO1B0O92iWIAVwq6aDE8p PdpZwc94ZvOJg== X-Received: by 2002:a17:902:e542:b0:2d6:3c1a:85ef with SMTP id d9443c01a7336-2df7dfc93c6mr35028765ad.4.1790261669688; Thu, 24 Sep 2026 07:54:29 -0700 (PDT) Received: from jfliu-sfa1411.. ([129.227.183.200]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2df6a5c3a3dsm28629285ad.43.2026.09.24.07.54.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 07:54:29 -0700 (PDT) From: Jianfeng Liu To: Rob Clark Cc: Bryan O'Donoghue , =?UTF-8?q?Christian=20K=C3=B6nig?= , Dmitry Baryshkov , dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v1 1/2] dma-buf: keep DMABUF_DEBUG off by default Date: Thu, 24 Sep 2026 22:54:18 +0800 Message-ID: <20260924145419.47354-1-liujianfeng1994@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: <20260923074256.9357-1-liujianfeng1994@gmail.com> Content-Type: text/plain; charset=UTF-8 Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Rob, On Thu, Sep 24, 2026 at 7:01 AM Rob Clark wrote: > So the assessment of what is going wrong looks pretty wrong.. VM_BIND > should never lead to iommu_map_sgtable() (which is never used for gpu > per-process pgtables), for example.. but is used for mapping for > scanout. And pages are never used for mapping in either path. > > However there are a few places where sg->length is used (in iommu code > and msm).. AFAICT dma_buf_wrap_sg_table() zeroing out sg->length is > what the actual problem here is, rather than any use of struct page. Thanks for the correction - you're right, I mis-traced the GPU path. The per-process pgtable mapping goes through msm_iommu_pagetable_map(), which walks the sg_table with sg->length and sg_phys(). With the wrapper zeroing sg->length it iterates the entries, maps nothing at all and still returns 0 - which explains the UCHE translation faults without any error anywhere, and is a nastier failure mode than the async-bind-failure story I wrote in the commit log. With that corrected picture, DMABUF_DEBUG=y breaks msm in the map paths themselves: msm_iommu_pagetable_map() for the GPU and iommu_map_sg() for scanout both consume sg->length, and dma_buf_wrap_sg_table() zeroes it, so every mapping of a page-stripped sg_table silently maps nothing. On top of that msm also uses sg_phys() in those paths and drm_prime_sg_to_page_array() for the page array, so even with sg->length preserved, page-less entries would map garbage physical addresses instead of failing loudly. So it looks like this needs work on both sides: - dma-buf: preserve sg->length in the debug wrapper, so sg->length consumers at least fail loudly instead of silently mapping nothing. I think that is what both Christian's "we should probably change that" and your "zeroing out sg->length is what the actual problem is" are pointing at. - msm: stop consuming struct page and sg->length of imported sg_tables, i.e. build the GPU and scanout mappings from the DMA addresses, plus the drm_prime_sg_to_page_array() cleanup. Is that the right split, and is there a preferred direction for the msm side? > (And yeah, I should get rid of use of drm_prime_sg_to_page_array().. > but that cleanup that I haven't found time for shouldn't be the > problem here.) Agreed on it not being what produced the faults - but it is part of the same contract problem, see below. Also answering Bryan's review of patch 2, which is in a different branch of this thread: On Thu, Sep 24, 2026 at 10:36 AM Bryan O'Donoghue wrote: > Why is the fix Adreno specific ? > > Shouldn't this function be ammended with > > > + if (filled != npages) > > instead ? It isn't meant to be - msm_gem_import() is the shared GPU/DPU import path. And putting the fill-count check into drm_prime_sg_to_page_array() itself would indeed be the better generic version of that guard; I checked the other callers (etnaviv, omapdrm, vmwgfx, xen) and none of them expects a partial fill either. But with the corrected analysis above, the page array isn't what produced the GPU faults, so neither variant is a real fix. I'm not asking for either patch to be merged - the series is a bug report with code attached, sent to get exactly this discussion going, which is also why it carries the RFC prefix. > This very much looks like an LLM generated patch - the commit log, the > large comment in the code and TBH the solution too. Sorry about that - the patches were drafted with LLM assistance and I should have declared that up front. Any later version will carry a proper declaration. Thanks all! Jianfeng