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 94DDD1A23B9; Mon, 19 Jan 2026 10:20:05 +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=1768818005; cv=none; b=PhAsbufV3U9aCbJeQWeW2W7prCS2X71cnj2eb+NImsSMktBnAxjQW3Sc0cJyajcf136EmVQLaWHUX7iq5J/9e1tTt1R07KWH6s6K6Piqg0uChXd4Vk0wJdPop20x45n/fgjbAYSx+TPnhJoH9lbsuUYSq3tOaEdfEY2NGpoJDY4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768818005; c=relaxed/simple; bh=2RDjQUZMhmdWBYNRZtH/kkwU0r9gHkrCC4kz2CcBePY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ShOJ1I5KbPTMyzf0MlkYApTuwJR82jyY7kVFeAb7UtwnkqUb3kRSVI9cJLf1Z5hwT/Yqu3I7+yFtJp32mAhjKijGPe84mT6ewdY078OA1la1g3aWt5BsG8K/KX9h14XiiPEOnHk2nMZGKIhah0kMeMbeXM/r3x63PYWQwu0UFJc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DxrQQXAa; 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="DxrQQXAa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 992BBC116C6; Mon, 19 Jan 2026 10:20:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768818005; bh=2RDjQUZMhmdWBYNRZtH/kkwU0r9gHkrCC4kz2CcBePY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DxrQQXAaI0qp3UxT5FitNpNW3Y9svXeBpnJR8Mwvk24SmBQfuUIB86Rn8wh4a/ecQ pixwE/Z1cQ7jAwH5Xn4fAmSy+WAHOtmuhwbgMe1tcgyZoc2JxN67BOiUkLlG7dAZ4l khAt25iuWNQOrsVRWjFsFCLlai/63P8eDcFYXOtI6ejGK+Cu+Dry69rHRjOgbENrNO lPdh+8a9nXnyzv60+Z+ElrFp0rGvrInDnteHpR0Bd8RjB1i7CfWg3ENBjJ/z6EqW2a e2HuPDKEOpE3UjazOeYLrGHAjL5NuqIVqBfBtCuolSeMuXg4lb7kuRYhoBwXGm6Ty2 nMhOuNmDbrRGw== Date: Mon, 19 Jan 2026 12:20:00 +0200 From: Leon Romanovsky To: Thomas =?iso-8859-1?Q?Hellstr=F6m?= Cc: Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , Alex Deucher , David Airlie , Simona Vetter , Gerd Hoffmann , Dmitry Osipenko , Gurchetan Singh , Chia-I Wu , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Lucas De Marchi , Rodrigo Vivi , Jason Gunthorpe , Kevin Tian , Joerg Roedel , Will Deacon , Robin Murphy , Alex Williamson , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, virtualization@lists.linux.dev, intel-xe@lists.freedesktop.org, linux-rdma@vger.kernel.org, iommu@lists.linux.dev, kvm@vger.kernel.org Subject: Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Message-ID: <20260119102000.GH13201@unreal> References: <20260118-dmabuf-revoke-v2-0-a03bb27c0875@nvidia.com> <20260119075229.GE13201@unreal> <9112a605d2ee382e83b84b50c052dd9e4a79a364.camel@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@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: <9112a605d2ee382e83b84b50c052dd9e4a79a364.camel@linux.intel.com> On Mon, Jan 19, 2026 at 10:27:00AM +0100, Thomas Hellström wrote: > On Mon, 2026-01-19 at 09:52 +0200, Leon Romanovsky wrote: > > On Sun, Jan 18, 2026 at 03:16:25PM +0100, Thomas Hellström wrote: > > > Hi, Leon, > > > > > > On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote: > > > > Changelog: > > > > v2: > > > >  * Changed series to document the revoke semantics instead of > > > >    implementing it. > > > > v1: > > > > https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com > > > > > > > > ----------------------------------------------------------------- > > > > ---- > > > > ---- > > > > This series documents a dma-buf “revoke” mechanism: to allow a > > > > dma- > > > > buf > > > > exporter to explicitly invalidate (“kill”) a shared buffer after > > > > it > > > > has > > > > been distributed to importers, so that further CPU and device > > > > access > > > > is > > > > prevented and importers reliably observe failure. > > > > > > > > The change in this series is to properly document and use > > > > existing > > > > core > > > > “revoked” state on the dma-buf object and a corresponding > > > > exporter- > > > > triggered > > > > revoke operation. Once a dma-buf is revoked, new access paths are > > > > blocked so > > > > that attempts to DMA-map, vmap, or mmap the buffer fail in a > > > > consistent way. > > > > > > This sounds like it does not match how many GPU-drivers use the > > > move_notify() callback. > > > > No change for them. > > > > > > > > move_notify() would typically invalidate any device maps and any > > > asynchronous part of that invalidation would be complete when the > > > dma- > > > buf's reservation object becomes idle WRT DMA_RESV_USAGE_BOOKKEEP > > > fences. > > > > This part has not changed and remains the same for the revocation > > flow as well. > > > > > > > > However, the importer could, after obtaining the resv lock, obtain > > > a > > > new map using dma_buf_map_attachment(), and I'd assume the CPU maps > > > work in the same way, I.E. move_notify() does not *permanently* > > > revoke > > > importer access. > > > > This part diverges by design and is documented to match revoke > > semantics.  > > It defines what must occur after the exporter requests that the > > buffer be  > > "killed". An importer that follows revoke semantics will not attempt > > to call  > > dma_buf_map_attachment(), and the exporter will block any remapping > > attempts  > > regardless. See the priv->revoked flag in the VFIO exporter. > > > > In addition, in this email thread, Christian explains that revoke > > semantics already exists, with the combination of dma_buf_pin and > > dma_buf_move_notify, just not documented: > > https://lore.kernel.org/all/f7f1856a-44fa-44af-b496-eb1267a05d11@amd.com/ > > > Hmm, > > Considering > > https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/infiniband/core/umem_dmabuf.c#L192 > > this sounds like it's not just undocumented but also in some cases > unimplemented. Yes, it was discussed later in the thread https://lore.kernel.org/all/20260112153503.GF745888@ziepe.ca/. RDMA will need some adjustments later, but first we need to document the existing semantics. > The xe driver for one doesn't expect move_notify() to be > called on pinned buffers, so if that is indeed going to be part of the > dma-buf protocol, wouldn't support for that need to be advertised by > the importer? This is what Jason proposed with "enum dma_buf_move_notify_level", but for some reason we got no responses. Thanks > > Thanks, > Thomas > > > > > Thanks > > > > > > > > /Thomas > > > > > > > > > > > > > > Thanks > > > > > > > > Cc: linux-media@vger.kernel.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: linaro-mm-sig@lists.linaro.org > > > > Cc: linux-kernel@vger.kernel.org > > > > Cc: amd-gfx@lists.freedesktop.org > > > > Cc: virtualization@lists.linux.dev > > > > Cc: intel-xe@lists.freedesktop.org > > > > Cc: linux-rdma@vger.kernel.org > > > > Cc: iommu@lists.linux.dev > > > > Cc: kvm@vger.kernel.org > > > > To: Sumit Semwal > > > > To: Christian König > > > > To: Alex Deucher > > > > To: David Airlie > > > > To: Simona Vetter > > > > To: Gerd Hoffmann > > > > To: Dmitry Osipenko > > > > To: Gurchetan Singh > > > > To: Chia-I Wu > > > > To: Maarten Lankhorst > > > > To: Maxime Ripard > > > > To: Thomas Zimmermann > > > > To: Lucas De Marchi > > > > To: Thomas Hellström > > > > To: Rodrigo Vivi > > > > To: Jason Gunthorpe > > > > To: Leon Romanovsky > > > > To: Kevin Tian > > > > To: Joerg Roedel > > > > To: Will Deacon > > > > To: Robin Murphy > > > > To: Alex Williamson > > > > > > > > --- > > > > Leon Romanovsky (4): > > > >       dma-buf: Rename .move_notify() callback to a clearer > > > > identifier > > > >       dma-buf: Document revoke semantics > > > >       iommufd: Require DMABUF revoke semantics > > > >       vfio: Add pinned interface to perform revoke semantics > > > > > > > >  drivers/dma-buf/dma-buf.c                   |  6 +++--- > > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c |  4 ++-- > > > >  drivers/gpu/drm/virtio/virtgpu_prime.c      |  2 +- > > > >  drivers/gpu/drm/xe/tests/xe_dma_buf.c       |  6 +++--- > > > >  drivers/gpu/drm/xe/xe_dma_buf.c             |  2 +- > > > >  drivers/infiniband/core/umem_dmabuf.c       |  4 ++-- > > > >  drivers/infiniband/hw/mlx5/mr.c             |  2 +- > > > >  drivers/iommu/iommufd/pages.c               | 11 +++++++++-- > > > >  drivers/vfio/pci/vfio_pci_dmabuf.c          | 16 > > > > ++++++++++++++++ > > > >  include/linux/dma-buf.h                     | 25 > > > > ++++++++++++++++++++++--- > > > >  10 files changed, 60 insertions(+), 18 deletions(-) > > > > --- > > > > base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb > > > > change-id: 20251221-dmabuf-revoke-b90ef16e4236 > > > > > > > > Best regards, > > > > --  > > > > Leon Romanovsky > > > > > > > >