[Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

[Chris Wilson]

On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote:
> > 
> > On 09/10/15 09:55, Daniel Vetter wrote:
> > >On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote:
> > >>On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote:
> > >>>On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote:
> > >>>The concern is that this isn't how SIG_SEGV works, it's a signal the
> > >>>thread who made the invalid access gets directly. You never get a SIG_SEGV
> > >>>for bad access someone else has made. So essentially it's new ABI.
> > >>
> > >>SIGBUS. For which the answer is yes, you can and do get SIGBUS for
> > >>actions taken by other processes.
> > >
> > >Oh right I always forget that SIGBUS aliases with SIGIO. Anyway if
> > >userspace wants SIGIO we just need to provide it with a pollable fd and
> > >then it can use fcntl to make that happen. That's imo a much better api
> > >than unconditionally throwing around signals. Also we already have the
> > >reset stats ioctl to tell userspace that its gpu context is toats. If
> > >anyone wants that to be pollable (or even send SIGIO) I think we should
> > >extend that, with all the usual "needs userspace&igt" stuff on top.
> > 
> > I don't see that this notification can be optional. Process is confused
> > about its memory map use so should die. :)
> > 
> > This is not a GPU error/hang - this is the process doing stupid things.
> > 
> > MMU notifiers do not support decision making otherwise we could say
> > -ETXTBUSY or something on munmap, but we can't. Not even sure that it would
> > help in all cases, would have to fail clone as well and who knows what.
> 
> So what happens if the gpu just keeps using the memory? It'll all be
> horribly undefined behaviour and eventually it'll die on an -EFAULT in
> execbuf, but does anything else bad happen?

We don't see an EFAULT unless a miracle occurs, and the stale pages
continue to be read/written by other processes (as well as the client).
Horribly undefined behaviour with a misinformation leak.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre