On Wed, Apr 09, 2014 at 06:50:03PM +0200, Daniel Vetter wrote: > On Wed, Apr 09, 2014 at 04:03:23PM +0100, Chris Wilson wrote: > > On Wed, Apr 09, 2014 at 04:49:02PM +0200, Daniel Vetter wrote: > > > On Wed, Apr 09, 2014 at 08:03:39AM +0100, Chris Wilson wrote: > > > > We neither report any unfinished operations during releasing GEM objects > > > > associated with the file, and even if we did, it is bad form to report > > > > -EINTR from a close(). > > > > > > > > The root cause of the bug that first showed itself during close is that > > > > we do not do proper live tracking of vma and contexts under full-ppgtt, > > > > but this is useful piece of defensive programming enforcing our > > > > userspace API contract. > > > > > > > > Cc: Ben Widawsky <benjamin.widawsky@xxxxxxxxx> > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > > > I'd really prefer something annoying and loud like we've done when nuking > > > the deferred free list in > > > > > > commit 1488fc08c1706288616c602416654fd38c773deb > > > Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > Date: Tue Apr 24 15:47:31 2012 +0100 > > > > > > drm/i915: Remove the deferred-free list > > > > > > where we've added a WARN_ON in gem_free_object if any unbind was failing > > > due to interrupts. This patch here disables that imo useful safety check. > > > > It doesn't classify as a safety check if kernel/userspace explodes. The > > trick would be to somehow get the error code back. And in this case we > > cannot accept any error anyway. So yes, I would like a nice big warning > > to catch bugs, but that is icing on the cake compared to preventing bugs > > from destroying data. > > Hm ... double-checking: This is just for full ppgtt, right? I think in > that case I prefer if people working on it just carry this around locally. > Otherwise I need to freak out ;-) The current bug under discussion is full-ppgtt (well, hopefully). I'd prefer it if we could prevent driver bugs leaking out into userspace... Pretty much everywhere we could hit an error but can't report one is simmering trouble. (And to continue playing the fiddle, and when the driver does explode, I expect to be able to continue using all the memory management and modesetting intefaces.) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
