dma-buf and ->dev refcount fun

[Daniel Vetter]

On Tue, Mar 25, 2014 at 4:53 AM, Dave Airlie <airlied at gmail.com> wrote:
> So I've got a reproducable oops with udl sharing from i915,
>
> start X, connect UDL, randr it into position, rip out udl device, kill X,
>
> we get an oops when dma_unmap_sg in i915_gem_unmap_dma_buf gets
> called, attachment->dev is pointing to a freed structure, now the drm
> + udl driver points dev->dev at the USB interface device, however when
> the device is unplugged, the USB interface device disappears in a poof
> of smoke, and we just keep a fake shell of the drm device around to
> keep userspace happy.
>
> So I'm wondering if should be using a different device to create
> dma-buf objects or whether dma-buf objects need to be keeping a
> reference on the interface device,

Don't do any mapping/attaching then since you never need to do dma
anyway. And I guess if we ever need to do dma with usb devices for
real we just need to teach the usb core about dma-bufs, so that the
*hci can do the attaching and dma-mapping.

On a quick look through udl_gem.c vmap will keep on working since it's
already forwarded to i915. That leaves mmap - either your userspace
doesn't need this for prime buffers or you'd need to implement that
one too. Rob Clark had patches floating around for forwarding mmaping
through dma-bufs between gem drivers a long time ago, Rob Bradford is
working on dma-buf mmap support for i915.

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.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch