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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
