linux-kernel - Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9679639cc7d9c2a27c5529484546faa65013f261.camel@linux.intel.com>
Date: Mon, 19 Jan 2026 18:24:16 +0100
From: Thomas Hellström <thomas.hellstrom@...ux.intel.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Leon Romanovsky <leon@...nel.org>, Sumit Semwal
 <sumit.semwal@...aro.org>,  Christian König	
 <christian.koenig@....com>, Alex Deucher <alexander.deucher@....com>, David
 Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Gerd Hoffmann
 <kraxel@...hat.com>,  Dmitry Osipenko <dmitry.osipenko@...labora.com>,
 Gurchetan Singh <gurchetansingh@...omium.org>, Chia-I Wu	
 <olvaffe@...il.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
  Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann
 <tzimmermann@...e.de>, Lucas De Marchi	 <lucas.demarchi@...el.com>, Rodrigo
 Vivi <rodrigo.vivi@...el.com>, Kevin Tian	 <kevin.tian@...el.com>, Joerg
 Roedel <joro@...tes.org>, Will Deacon	 <will@...nel.org>, Robin Murphy
 <robin.murphy@....com>, Alex Williamson	 <alex@...zbot.org>,
 linux-media@...r.kernel.org, 	dri-devel@...ts.freedesktop.org,
 linaro-mm-sig@...ts.linaro.org, 	linux-kernel@...r.kernel.org,
 amd-gfx@...ts.freedesktop.org, 	virtualization@...ts.linux.dev,
 intel-xe@...ts.freedesktop.org, 	linux-rdma@...r.kernel.org,
 iommu@...ts.linux.dev, kvm@...r.kernel.org
Subject: Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate
 shared buffers

On Mon, 2026-01-19 at 12:24 -0400, Jason Gunthorpe wrote:
> On Mon, Jan 19, 2026 at 10:27:00AM +0100, Thomas Hellström wrote:
> > this sounds like it's not just undocumented but also in some cases
> > unimplemented. 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?
> 
> Can you clarify this?
> 
> I don't see xe's importer calling dma_buf_pin() or dma_buf_attach()
> outside of tests? It's importer implements a fully functional looking
> dynamic attach with move_notify()?
> 
> I see the exporer is checking for pinned and then not calling
> move_notify - is that what you mean?

No it was if move_notify() is called on a pinned buffer, things will
probably blow up.

And I was under the impression that we'd might be pinning imported
framebuffers but either we don't get any of those or we're using the
incorrect interface to pin, so it might not be a big issue from the xe
side. Need to check this.

In any case we'd want to support revoking also of pinned buffers moving
forward, so question really becomes whether in the mean-time we need to
flag somehow that we don't support it.

Thanks,
Thomas


> 
> When I looked through all the importers only RDMA obviously didn't
> support move_notify on pinned buffers.
> 
> Jason