Re: [Spice-devel] [PATCH 09/11] Move main reference counter to GEM object instead of TTM ones

[Frediano Ziglio <fziglio@redhat.com>]

> On 27 May 2015 at 20:04, Frediano Ziglio <fziglio@redhat.com> wrote:
> > qxl_bo structure has two reference counters, one in the GEM object and
> > another in the TTM object. The GEM object keep a counter to the TTM object
> > so when GEM counter reached zero the TTM counter (using qxl_bo_unref) was
> > decremented. The qxl object is fully freed (both GEM and TTM part are
> > cleaned)
> > when the TTM counter reach zero.
> > One issue was that surface idr structure has no owning on qxl_bo objects
> > however
> > it contains a pointer to qxl_bo object. This caused some nasty race
> > condition
> > for instance qxl_bo object was reaped even after counter was already zero.
> > This patch fix these races moving main counter (the one used by
> > qxl_bo_(un)ref)
> > to GEM object which cleanup routine (qxl_gem_object_free) remove the idr
> > pointer
> > (using qxl_surface_evict) when the counters are still valid.
> 
> Uggh, but yes, not sure I like this fix for the problem, but if it works,
> 
> Reviewed-by: Dave Airlie <airlied@redhat.com>
> 

Well, the patch does not surely looks very clear but I can assure the problems it fixes are much less clear to understand.
Having a pointer to a object the is going to be deleted whenever another thread decide to causes difficult races. I tried to avoid this kind of change and fix the races instead but was a nightmare.
My first experimental patch added an additional counter on top of GEM and TTM one as the main counter but at the end was much more complicated and result was similar to move the main counter to GEM.
Mainly external references (from userspace and kernel) are pointers to GEM. Pointers to TTM are from memory mapped files. Deleting the spice id after GEM object has no references assure the not owning reference from spice id still refer to a valid object. As user can't retrieve a pointer from a mapping (at most can remap it) so there are no risks counter to GEM is incremented again.

Frediano