On Thu, 28 May 2020 16:45:45 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Thu, May 28, 2020 at 03:27:57PM +0300, Pekka Paalanen wrote:

...

> > Hmm. Maybe Wayland compositors should ignore all EGL import failures
> > that happen after the wl_buffer has been created (which implies that
> > the dmabuf has been validated to work initially). When import fails at
> > a later time, the compositor should just paint some error pattern
> > instead of the window. That would let the kernel keep on returning
> > errors.
> > 
> > Yeah, ok. I'll keep the ENODEV there in my next version. Let's see how
> > that looks then.  
> 
> tbh I have no idea what to do with dma-buf shared across drivers.
> 
> For dma-fence it's fairly simple: Force-complete them all, with an error
> code of ENODEV. But for dma-buf I have no idea. As long as the dma-buf
> sits in system memory it should keep working, plus/minus bugs in the
> exporter where it tries to look at device state that might no longer be
> there.
> 
> The real fun starts when the buffer is in vram, or when the mmap somehow
> goes through the device (but that's more a case for integrated gpu, and
> it's a bit hard to hotunplug those and consider that a real use-case).

Is forced driver unbind not a real use-case, or would it not invalidate
the memory references wrapped in a dmabuf?

In the proposal, I listed driver unbind as a use-case.

I don't mind if cross-driver shared dmabuf needed ten years of kernel
internals development to reach a state where it won't explode anymore,
but that's the goal I want to set today. I don't think we can tell
userspace to never share dmabufs cross-device if the exporter device is
hot-unpluggable, can we?


Thanks,
pq