Re: dma-buf and ->dev refcount fun

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Mar 25, 2014 at 10:40:45AM +0100, David Herrmann wrote:
> Hi
> 
> On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > Besides the issue at hand though I think drivers need to make sure
> > that the device they use for attaching does outlive the dma-buf. Which
> > for real hotpluggin probably means that drivers need to drop all
> > attachment on unplug (the dma mapping is useless anyway) and just keep
> > all their imported gem objects alive with just a reference to the
> > dma-buf object itself.
> 
> Drivers should never touch other drivers or even look at them. There
> is no reason i915 is responsible of keeping udl alive. That gets
> really messy and may introduce circular dependencies.
> 
> I'd like to see exported dma-bufs reference their drm-device owner.
> This way, the drm-device stays around until the dma-buf is removed. To
> avoid lazy device destruction, a driver can (during unplug) simply
> detach all dma-bufs if, and only if, they first made the dma-buf
> somehow stand-alone.
> 
> For example: udl can just move the allocated pages into the dma-buf,
> mark it as dead and detach it. The udl-device can get destructed and
> whenever i915 releases the dma-buf, the udl-dma-buf ops see it's dead
> and just deref it / release dma-buf resources. But this is all not
> needed if the exported dma-bufs just reference "drm_device", which is
> imho the easiest fix.

The issue at hand is the other way round, i.e. i915 exporting, udl
importing. The i915/dma-buf falls over because the device struct
referenced in the attachment disappeared. Dave fixed it by grabbing a
reference, I think the better fix would be to simply not attach (since udl
doesn't need it anyway). Either works.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch