drm prime/dma-buf import lifetime issue

Dave Airlie airlied at gmail.com
Mon Dec 17 20:38:17 PST 2012


So I've gotten back to playing with prime for a day, and found some
old intel/radeon tests I had failing,

Tracked it down to a lifetime issue with the current code and can
think of two fixes,

The problem scenario is

1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object

So we end up at this point, with a imported buffer record for the
dma_buf on the i915 file private.

Now if a subsequent test (without closing the drm fd) reallocates the
dma_buf with the same address, we can end up seeing that.

So why doesn't that reference get cleaned up?

So the reference gets added above at step 2, and when radeon unrefs
the object, i915 gets the dma-buf release callback, however at that
stage
we don't actually have the file priv to remove the pointer from, so it
dangles there.

Possible fixes:

a) take a reference on the dma_buf attached to the gem handle when we
export it, keep it until the gem handle goes away. I'm unsure if this
could create zombie objects, since the dma buf has a reference on the
gem object, but since the gem handle is separate to the object it
might work.

b) don't keep track of dma_buf, keep track of gem objects, when we get
a lookup, check inside the gem object, since currently we NULL out the
export_dma_buf when we hit the release path, apart from the fact I'm
sure the locking is foobar,

c) scan all the file privs for all the devices, no.

Anyone else any better plans?

Dave.


More information about the dri-devel mailing list