[PATCH] drm/gem: Internally test import_attach for imported objects

[Simona Vetter]

On Tue, Apr 15, 2025 at 03:57:11PM +0200, Christian König wrote:
> Am 15.04.25 um 15:10 schrieb Simona Vetter:
> >> This is for devices who only want to do a vmap of the buffer, isn't it?
> > ... it's for the vmap only case, where you might not even have a struct
> > device. Or definitely not a reasonable one, like maybe a faux_bus device
> > or some device on a bus that really doesn't do dma (e.g. spi or i2c), and
> > where hence dma_buf_map_attachment is just something you never ever want
> > to do.
> 
> Even in that case I would still suggest to at least create an attachment to let the exporter know that somebody is doing something with it's buffer.
> 
> That is also important for move notification since you can't do those without an attachment.
> 
> BTW: What is keeping a vmap alive after dropping the reservation lock? There is no pinning whatsoever as far as I can see.

dma_buf_vmap should also pin, or something will go wrong very badly. And
that also can tell the exporter what exactly the buffer is used for
(kernel cpu access). I really don't think we should mix that up with
device access as a dma_buf_attachment.
-Sima

> 
> > I think we might want to transform obj->import_attach into a union or
> > tagged pointer or something like that, which can cover both cases. And
> > maybe a drm_gem_bo_imported_dma_buf() helper that gives you the dma_buf no
> > matter what if it's imported, or NULL if it's allocated on that
> > drm_device?
> 
> Yeah, I had the same idea before as well. Just didn't know if that was something worth looking into.
> 
> Regards,
> Christian.
> 
> >
> > Cheers, Sima

-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch