From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 14C13C61DD6 for ; Wed, 2 Sep 2026 09:53:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4884D10E495; Wed, 2 Sep 2026 09:53:45 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="SDO/E4ot"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id 39DD110E495 for ; Wed, 2 Sep 2026 09:53:44 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 13029600D9; Wed, 2 Sep 2026 09:53:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 349411F000E9; Wed, 2 Sep 2026 09:53:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788342822; bh=aF/Kk+g5mXV8rPuEMfzI6XMNGLVQ9aLTLmy5wSXsqwA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=SDO/E4otLAYdA2G9JfptpWzIkyPnU/okkQE6y7+fCD0bH5mhWgvxm0KoD6u64lN37 q6DUrJbwr/YDn6hn/FEIG/Utjy8NU2kRmfLXbQZGaD6z7eU47RlEnZlLyG4X48FsVv 0rSyEFL7b6DWdwm4/cNVQ1wh22bwGg3n/Zr9RRmGDLS77ffYSGTYbub2sW0uJin5dX 0g9svPDUsfhWsEAmm5jo9uDJaq7jOOkALaWpX9lz334szFrK99859mo6IESO4jcwcD EH0/dC11zvpDkwpd16t+pDSzO1RCGgNKpVKMit//wAS4lpqoFnm4V88KaBACOJ81ip eWnPNFVRIQZJg== Date: Wed, 2 Sep 2026 12:53:38 +0300 From: Leon Romanovsky To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: David Hu , sumit.semwal@linaro.org, alex@shazbot.org, ankita@nvidia.com, chriscli@google.com, david.laight.linux@gmail.com, dri-devel@lists.freedesktop.org, iommu@lists.linux.dev, jgg@ziepe.ca, jmoroni@google.com, kevin.tian@intel.com, kpberry@google.com, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, nicolinc@nvidia.com, praan@google.com, sashiko-bot@kernel.org, stable@vger.kernel.org, viursachi@google.com, xuehaohu@google.com Subject: Re: [PATCH v8 0/2] dma-buf: Fix silent overflow and alignment Message-ID: <20260902095338.GU24140@unreal> References: <20260901170849.4052816-1-dhu@x6u.co> <2bf581db-7cc5-4f38-a075-1b988c332f3c@amd.com> <20260902073936.GR24140@unreal> <20260902083232.GT24140@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Sep 02, 2026 at 10:44:59AM +0200, Christian König wrote: > On 9/2/26 10:32, Leon Romanovsky wrote: > > On Wed, Sep 02, 2026 at 09:56:06AM +0200, Christian König wrote: > >> On 9/2/26 09:39, Leon Romanovsky wrote: > >>> On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote: > >>>> On 9/1/26 19:08, David Hu wrote: > >>>>> From: David Hu > >>>>> > >>>>> This series address two related issues in scatter-gather mapping, > >>>>> specifically for the MMIO based dma-buf mapping. The fixes ensure > >>>>> sgt mapping is correct, and proper for large MMIO regions. > >>>>> > >>>>> Patch 1 fixes a silent integer overflow for mapping length exceeding 4G > >>>>> (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for > >>>>> phys vec to sgt) > >>>>> https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ > >>>>> > >>>>> Patch 2 Splits sgl by largest page aligned chunk > >>>>> (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) > >>>>> https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ > >>>> > >>>> *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. > >>> > >>> And this is why so many in the kernel community want to get rid of SG > >>> lists. It would be great if DMA-BUF could also eliminate the need to > >>> convert to an SGL, like Jason proposed. > >>> > >>> The DMA layer no longer needs SGL. These bugs belong to the DMA-BUF layer, > >>> which is the one that depends on it. > >> > >> I'm all fine using an array/xarray of dma_addr_t in DMA-buf, just phys_vec is a clear no-go. > > > > You are proposing the same thing as an SGL, just in a different format. > > Yes, because that is the right thing todo as far as I can see. > > > It does not address the issue that dma_addr_t is expected to hold a DMA > > address, while that is not always the case. For example, in the P2P case, > > the addresses are not DMA addresses. > > Yes they are. They must be DMA addresses because that is the only thing the importer needs to do it's DMA. They can perform DMA, but that still does not make them suitable for the dma_addr_t type. For the PCI_P2PDMA_MAP_BUS_ADDR flow, these addresses follow completely different rules: they are not unmapped, require no cache synchronization, are valid only for peer access, and require separate error handling. All of this information is lost if only the dma_addr_t is stored. > > It can be that those are DMA addresses on private interconnects between devices, but it should *never* be a phys_addr_t because that is limited to the address space the CPU can see. > > > Jason's proposal: > > https://lore.kernel.org/all/0-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@nvidia.com/ > > Yeah, I have commented quite a bit on that. Right, I posted it for reference. Thanks > > Regards, > Christian. > > > > > Thanks > > > >> > >> Regards, > >> Christian. > >> > >>> > >>> Thanks > >> > >> > >