[Intel-gfx] [PATCH] drm/i915: Prevent signals from interrupting close()

[Daniel Vetter]

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 at intel.com>
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > 
> > 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 at chris-wilson.co.uk>
> > 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 ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch