dma-buf and ->dev refcount fun

Dave Airlie airlied at gmail.com
Tue Mar 25 03:11:22 PDT 2014


On Tue, Mar 25, 2014 at 7:40 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
> Hi
>
> On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter <daniel at 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.

I sent a patch to fix the udl case to just keep a reference on the
usb_interface device it seems to work,
we probably do need to do this in theory for pci devices as well in a
hotplug/sysfs plug situation I suppose,

Dave.


More information about the dri-devel mailing list