On Sat, Jun 1, 2013 at 1:51 AM, Chris Wilson <[email protected]> wrote: > On Fri, May 31, 2013 at 02:46:20PM -0700, Ben Widawsky wrote: >> The way the stolen handling works is we take a pin on the backing pages, >> but we never actually get a reference to the bo. On freeing objects >> allocated with stolen memory, the final unref will end up freeing the >> object with pinned pages count left. To enable an assertion to catch >> bugs in this code path, this patch cleans up that remaining pin. >> >> Signed-off-by: Ben Widawsky <[email protected]> > > That neatly explains the WARN. Not too happy about accumulating lots of > backing storage specific processing into free_object, but that can be > fixed up later (there is an obj->ops->release() pending).
I'm more irked with the semantic overloading of object pinning. Might be cleaner to otherwise mark stolen obejcts as not shrinkable instead of pinning them for their entire lifetime. But we can bikeshed that later on ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
